2016-05-09 13:25 GMT+02:00 RIT <[email protected]>: > Hi > > >> Just an idea: If you're using jOOQ for migrations with Flyway, the jOOQ >> code is really also just a text file (*.java). Taking the checksum of that >> would be easy. If you could manage to compile (and run) the jOOQ code after >> taking the checksum, that might work around your issue, no? Perhaps, that >> might be something worth requesting from Flyway as an enhancement. The >> ability to provide programmatic migrations in source format, letting Flyway >> compile the migration using the JDK's built-in compiler... >> >> Or, we build that on our end and ship a jOOQ-migrations module based on >> Flyway, as I've mentioned before. >> >> Tracking the *'.java is going to have to many complications as it is > likely to be changed during the development life cycle due to formatting > and the made rush to add documentation/comments at some point when someone > remembers to turn the metric scoring system on :) >
Then, compile the code first to create a hash over the bytecode. Bytecode won't depend on stylistic changes, formatting, commenting. Also tracking the source does not catch my previous example where the SQL > statement changes over time because JOOQ has gained capabilities to support > new features (BIT vs BOOL) which will result in no java changes, but will > result in different DDL. > That's true. But you could also include the jOOQ version in the above hash. > I've raised the issue with Flyway as a question on stackexchange as that > seems to be their primary way of communicating. Going forwards I would much > prefer to see Flyway become JOOQ friendly, rather than you having to fork > it for your own needs. > I'm sure my friend Axel is very open to suggestions that help him gain market share from Liquibase :) Please, I was not raising any concerns, rather just the issue of trying to > fit the fluent interface into a new edge case role which it was never > designed for. > I'm very open to those edge cases. After a while and several discussions, they will cristallise into features that are generally useful. > My own working knowledge is also a major factor here as I'm not a > development, my focus is networks, databases and infrastructure. To me > method chaining and fluent interfaces are new and shiny (then again they > have only really been talked about for just the last 10 years or so), so > moving into lambda expressions means I've got some catching up to do. > Lambda expressions are mostly just syntax sugar for anonymous classes, which Java had for 20 years. Swing wouldn't have been possible without them (think of ActionListeners, etc.) Hope this helps, 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.
