Hi Lukas Once again, thanks for your very nice answer.
I reply inline. > > > 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 > Sure, but actually I stumbled upon the Corporate Contributor Information part: my employer indeed works in software but has no policy I know of regarding Open Source and my contract is totally free of such restriction. I'll try to get some answer internally but I don't expect much (nor fast)... > > > 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. > ok well, actually I changed the way migration are triggered to have them done from a main method. It feels closer from "real life" to me, yet it makes the example a bit more complex. Is still fine for you ? If fine, I think I'll start with a github project and some markdown text for the documentation. > > >> 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 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FjOOQ%2FjOOQ%2Fissues%2F4232&sa=D&sntz=1&usg=AFQjCNGHO3vLhEMuejluyQ28ZTKXDKMuHQ> > Well, I'm unsure about annotation there. What if I deleted some columns, what to annotate? And changes could be subtler, like some type change, and then how to reflect this ? What if multiple changes were done over time ? > > It looks as though we can certainly learn from you here. > Not so fast ;) Actually we have the issue currently in our production code : changes over time are only visible in the migration files. Which has two main drawbacks : - migrations aren't typesafe (and in 10+ years of ongoing dev, typo were made, actually they happen something like twice a year) - in case of issue, figuring out what was before isn't always easy (especially when some migration actions were done, like altering data to fit into the new schema) But the solution I was thinking of is totally unproven up to know, so it's a bit earlier to say how good it is. Let see it in more details : > > >> 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? > Well, that's pretty simple, for example: package org.jooq.example.model.tables; public class Author extends org.jooq.example.model.previous.v3.tables.Author { } I'm thinking of doing it for every stuff from the generated model which is used at least once outside of the migration steps. So when a new migration is done, I simply have to change the extend to v4 and then typesafety kicks in and tells me of any issue. > > >> > (...) >> Does it look like a good approach? >> > > It does indeed. > Actually while doing it I was wondering about the verbosity of this approach. I end up with all tables/sequences/whatnot defined whereas only the delta really matters. That's why I'm unsure about it. On the other hand, type safe migration rocks :) > And I'd like to learn more about how you're doing this. > I will put it all on github so you can have a look. It's pretty simple right now (really just your doc sample rewritten) so easy to figure out I guess. Eager to have your feedback, I upload this all soon (as soon as possible but that may be by the end of the week only - sorry). > Specifically, if you find anything missing from jOOQ's DDL support, I'd > love to know - there's still lots of room for improvement! > Well, one little issue was the lack of unique support at table creation, I had to add the constraint later on: create.createTable(AUTHOR) .column(AUTHOR.ID, SQLDataType.INTEGER.nullable(false)) .column(AUTHOR.FIRST_NAME, SQLDataType.VARCHAR.length(50)) .column(AUTHOR.LAST_NAME, SQLDataType.VARCHAR.length(50).nullable(false)) .column(AUTHOR.DATE_OF_BIRTH, SQLDataType.DATE) .column(AUTHOR.YEAR_OF_BIRTH, SQLDataType.INTEGER) .column(AUTHOR.ADDRESS, SQLDataType.VARCHAR.length(50)) .execute(); create.alterTable(AUTHOR).add(constraint("PK_T_AUTHOR").primaryKey(AUTHOR.ID)).execute(); On the way I spotted as well that the constraint name isn't put in the generated stuff (at least as far as I've seen), which I guess could be an issue sometime (when changing it mainly, by dropping/create). Having it as well in the generated class would be sweet. > > 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. > Not so fast again ;) lol Anyway, I've some blog rusting somewhere, I'm not sure it's the best way to communicate around this topic. Let's see when we'll have discuss it more :) Best PS : I reply on the "[REQUEST FOR FEEDBACK] New jOOQ code generator: What do you want it to be?" another day > > Cheers, > Lukas > > 2016-01-04 0:10 GMT+01:00 <[email protected] <javascript:>>: > >> 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] <javascript:>. >> 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.
