On Aug 11, 2013, at 9:45, [email protected] wrote:
> An alternative is to use an embedded database, H2, for code generation during > the build. This requires maintaining a set of migration scripts for H2 (test) > and MySQL (prod), due to dialect differences. It works pretty well and though > some developers dislike the small amount of duplication no one prefers the > alternative of checking in generated code. We've taken the same approach, albeit with HSQL. We're using maven, so we a module dedicated to the codegen phase, it boots an HSQL in memory instance, the JOOQ maven plugin uses that to generate source, and then those get compiled as normal. At runtime we run this binary against Oracle, MySQL, Postgres, DB2 and SQL Server. I think the design clue with JOOQ is the fact that the runtime model is very database agnostic and hence is so portable. Most of the specifics of each database are handled in the SQL rendering phase, which is dialect aware. Most of the peculiarities of each DB arise with functions that are not supported identically against all databases, e.g. date truncation. However, these issues don't really affect the code generation phase, since it is primarily interested in building a structural model of your schema. Cheers, Ben -- 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/groups/opt_out.
