> > I'm very curious about your use-case. So, essentially, you have an > application that runs on e.g. Oracle, MySQL, PostgreSQL, and you write DDL > with jOOQ and execute it with Flyway on each database? >
Yes, that just about sums it up - many tools/applications come with an embedded database option and then allow the choice of one or more third party databases and I'm currently experimenting on how that can be handled without the need for independent SQL scripts per supported database. The ongoing work you are doing in JOOQ to support DDL generation becomes a very nice way to handle the DDL and Flyway provides nice Java level integration to handle and track schema changes. The end result could be the following - JOOQ DDL is used to express a compatible schema across a number of databases - Flyway handles the generation, tracking and upgrading of the schema on each database. - JOOQ generator creates the correct output for each database schema, maybe even down to the version level. The result of all of the above is that the developer(s) could end up with a library of JOOQ classes that map to all deployed versions of the database schema across all target databases. Such a library then becomes the foundation of any upgrade, migration and test tools that need to be developed. I'll be honest, this is not about writing a full application, but more about gaining an understanding of how different tools can be combined. In other words, the current implementation is probably safe for your > use-case. Note that it does depend on the SQLDialect (for obvious reasons) > and the Settings (for reasons like generating uppercase or lowercase > keywords, names, etc.), so you will get different hash codes if you're > using different database dialects. You could of course generate the hash > code always from the SQLDialect.DEFAULT dialect, for instance. > 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. On Friday, 6 May 2016 08:28:16 UTC+1, Lukas Eder wrote: > > Hi Roger, > > There is a general contract specified for QueryPart.hashCode() as > documented in the Javadocs: > http://www.jooq.org/javadoc/latest/org/jooq/QueryPart.html#hashCode-- > > It reads: > > In general, QueryPart hash codes are the same as the hash codes generated > from toString() > <http://www.jooq.org/javadoc/latest/org/jooq/QueryPart.html#toString-->. > This guarantees consistent behaviour with equals(Object) > <http://www.jooq.org/javadoc/latest/org/jooq/QueryPart.html#equals-java.lang.Object-> > > Some QueryPart implementations may choose to override this behaviour for > improved performance, as toString() > <http://www.jooq.org/javadoc/latest/org/jooq/QueryPart.html#toString--> is > an expensive operation, if called many times. > In other words, the current implementation is probably safe for your > use-case. Note that it does depend on the SQLDialect (for obvious reasons) > and the Settings (for reasons like generating uppercase or lowercase > keywords, names, etc.), so you will get different hash codes if you're > using different database dialects. You could of course generate the hash > code always from the SQLDialect.DEFAULT dialect, for instance. > > I'm very curious about your use-case. So, essentially, you have an > application that runs on e.g. Oracle, MySQL, PostgreSQL, and you write DDL > with jOOQ and execute it with Flyway on each database? > > Cheers, > Lukas > > > 2016-05-05 23:59 GMT+02:00 RIT <[email protected] <javascript:>>: > >> I am just wondering what is used to generate the hashCode in the >> following example code for createTable >> >> >> DSLContext create = DSL.using (connection, SQLDialect.DERBY); >> >> long val = create.createTable("tableName") >> .column("first", SQLDataType.BIT) >> .column("second", SQLDataType.TINYINT) >> .hashCode(); >> >> The reason for asking is that I am looking to combine JOOQ DDL capability >> with Flyway's schema management capabilities and this is best done by >> providing Flyway a checksum of each schema modification. This means that >> the hashCode should only be generated from the SQL statement that is to be >> executed rather than the wider information maintained by the DSLContext. >> >> If .hashCode in this situation does combine wider information I can just >> generate my own from the getSQL, but it would be good to know. >> >> The idea behind all of this is to use JOOQ's cross dialect capabilities >> to handle a couple of different database targets, rather than having to >> integrate yet another tool/library/definition stricture to do the the job. >> >> >> Thanks >> >> -- >> 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.
