Maybe I'm not understanding the problem properly but why couldn't you simply use version control and standard java maven/ivy/gradle/ release cycle to do this?
You have a snapshot of the schema (Jooq only inspects the schema anyways so it's not like that data matters much). When you commit a new change, it applies the SQL to a DB (real server, docker, vagrant, pick your poison ) and generates a jar file with all the generated classes with a pinned version. For step 1 of getting a jar compatible with the older version is just a matter of using an older release of the generated code. Does that make sense or am I over simplifying your problem? On Wed, Mar 23, 2016 at 9:23 AM, Patrick Armstrong < [email protected]> wrote: > Thanks for the information Lukas. > > Rollback would be an extreme situation I think, done by disconnecting the > MySQL secondary from the primary, then running the migration on the > primary, then if something goes wrong, restore from the secondary. > > The more typical situation would be: > > 1. Deploy Java code that is compatible with the old version of the schema > and the new schema > 2. Run the migration > 3. Deploy Java code that removed the compatibility with the old version of > the schema. > > The tricky part with JOOQ and code generation is step number 1 I think. > I’m not quite sure how I could use code generation in JOOQ with that type > of situation. > > > > On Mar 23, 2016, at 1:25 AM, Joseph Pachod <[email protected]> > wrote: > > Hi > > No worries for the CC'ing. > > For migrating up and down, you'll have to find a proper tool for it ( > https://flywaydb.org/ doesn't support migrating down AFAIK). > > On my side, just for migrating upwards, and needing all previous > migrations since we deploy on premises a > > On Tue, Mar 22, 2016 at 1:31 PM, Lukas Eder <[email protected]> wrote: > >> Hi Patrick, >> >> (Joseph, I hope you don't mind me CC'ing you for this discussion) >> >> Thank you very much for your e-mail. >> >> That is a very interesting idea, and we've actually had a very similar >> discussion here on the user group, just recently: >> https://groups.google.com/d/msg/jooq-user/I9iLbMQNN8o/Zrs-fi2bCQAJ >> >> I'm curious myself how Joseph Pachod (who was starting that discussion) >> finally managed to implement type safe versioning of their database with >> jOOQ. >> >> In any case, I don't think it's a good idea to edit generated classes >> manually. You don't know what kind of change we'll be implementing to >> support new features in the next jOOQ minor release... >> >> One approach that has served me well in the past was to avoid working >> with tables directly, but work with views instead, in order to hide (some) >> database migration details from the client. >> >> If you have any specific ideas / concerns, I'm very happy to discuss (and >> hopefully, others might chime in, too) >> >> Best, >> Lukas >> >> 2016-03-21 23:22 GMT+01:00 Patrick Armstrong < >> [email protected]>: >> >>> Hi there, >>> >>> I'm looking at using JOOQ for a project, and am curious about the idea >>> of using the code generation once per new table, then keeping these objects >>> updated manually afterwards as the database schema evolves. We are planning >>> on doing migrations without downtime, so we'd like the flexibility to be >>> able to rollback if there's a problem with an update, so code needs to be >>> able to work with a pre-migration and post-migration database. >>> >>> What do you think about that idea? Would it be better to just forgo the >>> code generation features in my use case? >>> >>> --patrick >>> >>> -- >>> 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. > > > -- > 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. > -- Thank you Samir Faci -- 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.
