Interesting thread, I missed it as January was a complicated month for me. If I come up with anything I'll try and create a post/readable example.
Interesting, so I guess the current hashCode() implementation will work > perfectly for you. One more caveat I have thought of: There is some small > risk of the hashCodes() (just like the SQL strings) changing between jOOQ > minor releases - e.g. when jOOQ slightly modifies the generated SQL in case > it needs some emulation. I don't think that will be a general problem > though, just something to keep in mind. > 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. On Friday, 6 May 2016 13:40:24 UTC+1, Lukas Eder wrote: > > Thank you very much for the additional feedback, Roger. > > There had recently been a very interesting, similar discussion on this > mailing list regarding a multi-version jOOQ/Flyway schema generation: > https://groups.google.com/d/msg/jooq-user/I9iLbMQNN8o/Zrs-fi2bCQAJ > > I'm definitely sensing a common use-case for many jOOQ users here. In the > next months, I will give this some deeper thought to see how jOOQ can > better integrate with Flyway, e.g. by supporting a "jOOQ migrations" > module. It does sound very interesting in any case. > > Looking forward to hearing how your experiments go > > 2016-05-06 14:21 GMT+02:00 RIT <[email protected] <javascript:>>: >> >> The hashcode/checksum only has to be consistent per target SQLDialect as >> it will be at this level that Flyway will be operating, so the above >> statement would indicate it should work just fine. Any changes to things >> like case configuration would blow up the whole codebase, so in many ways >> having Flyway report that all the hashcodes have changed would be a major >> benefit as it would indicate that something has changed which may otherwise >> be overlooked. >> > > Interesting, so I guess the current hashCode() implementation will work > perfectly for you. One more caveat I have thought of: There is some small > risk of the hashCodes() (just like the SQL strings) changing between jOOQ > minor releases - e.g. when jOOQ slightly modifies the generated SQL in case > it needs some emulation. I don't think that will be a general problem > though, just something to keep in mind. > > Cheers, > Lukas > -- 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.
