What is the best practice for DB migrations with E...

# exposed

[JP]

What is the best practice for DB migrations with Exposed? I want to use Flyway, but I'm having trouble seeing how it doesn't defeat the purpose of an ORM in some ways. Meaning, if I add Flyway, I have to add all the table definitions into a file and a upscript every time I want to change the schema along with modifying the Exposed table models. Is there an better way to do this? I thought I might be able to use the Flyway API and run the migrations after I create all of the tables with Exposed, but I'm having trouble getting this to work because Flyway wants to have table definitions in its history. Does anyone have experience with this, or best practice recommendations? At the end of the day, I'm just trying to add persistent data to my database without having it repeatedly inserted (i.e., every time I run the application, which is what a transaction would do in Exposed). If there is another tool other than Flyway that might be better suited for this, then I'd be happy to hear about that as well.

[Jonathan Mew]

We settled for maintaining a directory of (hand-written) SQL scripts for flyway to apply. I'd also be interested if anyone can suggest a better tool/process to work with Exposed.

[bitkid]

i also use flyway + exposed together with hand written scripts

[Semen Borisov]

Hey, have you figure out your own practices? I have the same questions now