2016-01-04 0:10 GMT+01:00 <[email protected]>: > Hi > > When reading the documentation, I was surprised to see the migration > scripts for flyway were all sql files and not java code, yet flyway > provides such hooks as well ( > http://flywaydb.org/documentation/migration/java.html). > > Is there a reason for sticking with sql files ? >
Yes! No way I'm going to migrate e.g. an Oracle database with Java, when there is PL/SQL. :-) But YMMV of course. Still, I've rewritten the "Using jOOQ with Flyway" part of the > documentation > http://www.jooq.org/doc/3.7/manual-single-page/#jooq-with-flyway with the > java based migration and jOOQ createTable statements and the like. I could > contribute it back if you wish so, let me know. > Sure, that would be very useful! Thank you very much for offering this. I would need you to sign the contributor agreement first: http://www.jooq.org/legal/contributions Then, you can contribute your changes in any way you find suitable. We currently don't host the manual sources on GitHub (yet), so a pull request is currently not possible, I'm afraid. > Still, while working on it and thinking how we currently do migrations at > work, with sql files, I felt like the approach taken in the documentation > was a bit "incomplete": each time a new migration is added, the model is > generated again and then one should look for compilation error. Don't get > me wrong, it's already pretty and for sure needed. Yet the complete > disparition of the previous model bothers me. At work we do like this and > from times to times it bits us back. How was it before? Why did we change > this stuff this way? Is it really the correct name for the old Foo columns? > That's true. It would be useful to maintain versions of the schema also in the "current" Java code, not only in version control. Sure, version controlling generated sources is one way to tackle the problem (there are some discussions around that on this list). But having all versions at runtime in some form might also be useful. We have a pending feature request for this, but haven't thought this through yet: https://github.com/jOOQ/jOOQ/issues/4232 It looks as though we can certainly learn from you here. > As such, I tried the following approach: > - a model package, containing mostly empty classes subclassing the latest > generated version > Interesting, could you give an example about this subclassing that you're doing? > - a package per previous version, named currently model.previous.vX. This > contains the generated code "at the time" and is used for the migration > scripts. > > When some change is to be done, I : > - create a new java migration, with just strings for the new stuff and > using the latest version model for the current state > - run the new migration > - generate the new model > - copy/paste the new model in model.previous.vX+1 > - update the migration script with the freshly generated model constants > - change the classes in the model package to extends this new model > contents > > The non migration code only uses the classes in the model package. > > In the end: > - history is preserved, > - the migration scripts are typesafe, > - non migration code isn't burdened by migration management. > > Does it look like a good approach? > It does indeed. And I'd like to learn more about how you're doing this. Specifically, if you find anything missing from jOOQ's DDL support, I'd love to know - there's still lots of room for improvement! What I think would be very useful for the community would be a blog post with more details, in case you do write blogs. I think you've found a great solution to something that many people are thinking about, and that neither jOOQ nor Flyway currently offer an out-of-the-box solution for. Cheers, Lukas 2016-01-04 0:10 GMT+01:00 <[email protected]>: > Hi > > When reading the documentation, I was surprised to see the migration > scripts for flyway were all sql files and not java code, yet flyway > provides such hooks as well ( > http://flywaydb.org/documentation/migration/java.html). > > Is there a reason for sticking with sql files ? > > Still, I've rewritten the "Using jOOQ with Flyway" part of the > documentation > http://www.jooq.org/doc/3.7/manual-single-page/#jooq-with-flyway with the > java based migration and jOOQ createTable statements and the like. I could > contribute it back if you wish so, let me know. > > Still, while working on it and thinking how we currently do migrations at > work, with sql files, I felt like the approach taken in the documentation > was a bit "incomplete": each time a new migration is added, the model is > generated again and then one should look for compilation error. Don't get > me wrong, it's already pretty and for sure needed. Yet the complete > disparition of the previous model bothers me. At work we do like this and > from times to times it bits us back. How was it before? Why did we change > this stuff this way? Is it really the correct name for the old Foo columns? > > As such, I tried the following approach: > - a model package, containing mostly empty classes subclassing the latest > generated version > - a package per previous version, named currently model.previous.vX. This > contains the generated code "at the time" and is used for the migration > scripts. > > When some change is to be done, I : > - create a new java migration, with just strings for the new stuff and > using the latest version model for the current state > - run the new migration > - generate the new model > - copy/paste the new model in model.previous.vX+1 > - update the migration script with the freshly generated model constants > - change the classes in the model package to extends this new model > contents > > The non migration code only uses the classes in the model package. > > In the end: > - history is preserved, > - the migration scripts are typesafe, > - non migration code isn't burdened by migration management. > > Does it look like a good approach? > > Thanks in advance > > Best > joseph > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
