2016-05-06 15:14 GMT+02:00 RIT <[email protected]>: > The issue of slight modifications to JOOQ's output is one of the reasons > why I started to look into this. Just using JOOQ DDL on its own could be a > major issue over time as the generated SQL will change. An example of this > would be say Derby adding support for BOOL, currently JOOQ generates DDL > based around INT. I'm sure that you would update JOOQ at some point to > support this and so it will generated different DDL statements. In a nice > clean developer environment such a change may go totally unnoticed as the > JOOQ DDL would update at the same time the JOOQ generated class output > would and so will be transparent to the developer(s). The fact that the > schema is now defined with a BOOL rather than an INT may go unnoticed until > deployed in a live environment where a third party report writer with > predefined reports based on a past version of the application has also been > deployed (I seen this happen with SQL DDL script based development) or a > schema based around INTs is already active ( I've also see this happen). > Introducing Flyway should catch this the first time the application is run > against an active schema and so hopefully during a CI cycle, or at least > provide detail about the issue if deployed into a live system and should > stop the application from even starting up and doing something bad, such as > a part upgrade. >
Huh, yes indeed, that's a very interesting caveat. So, any given migration would be tied to a concrete jOOQ version, if the SQL string is not stored, but the jOOQ DSL API calls are. Of course, it would be possible to migrate the migration scripts too, as: 1. jOOQ is generally rather backwards compatible 2. If it isn't (e.g. as you showed via BOOL types), then it's still possible to restore the old behaviour in new versions, e.g. using custom data type bindings In any case, it's important to detect such issues -- 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.
