Hello Witold, Comments inline to your first and second mail:
>> Is it possible to instruct JOOQ to use specific database to Java mapping >> by type? In documentation it is explained to specify forced mappings by >> table and column name, not type. For example, I have a NUMBER(4,0) column, >> JOOQ generates java.lang.Short. I would like all NUMBER(4,0) to be mapped as >> java.lang.Integer. Currently, this is only possible for DATE / TIMESTAMP types using the <dateAsTimestamp/> flag. This has the effect that all DATE columns will be treated as if they were TIMESTAMP columns. While this is a very important use-case for the Oracle database (whose DATE type is actually a TIMESTAMP with less precision than TIMESTAMP itself), I could think of many useful use-cases in other databases, which is why I had dropped the idea. What's the reason you prefer Integer over Short? Just convenience, circumventing Java's casting madness when it comes to using short and byte types? A possible solution that I see for your problem would be to introduce a <avoidByteAndShort/> sort of flag, that makes Integer (and UInteger) the smallest possible integer data type in jOOQ's generated code. >> P.S. >> One extra question: what is the pronunciation of JOOQ? Eeh... When I designed that acronym, I only had the logo with the ninja-esque face in mind. Only later, I realised that jOOQ is most straightforwardly prounounced as "joke". I don't know what's better. The English "joke" or the russian "bug" as Vladislav mentioned here ;-) http://stackoverflow.com/q/5625832/521799 >> P.P.S. >> JOOQ is GREAT! I use it together with Liquibase. It is a nice duet :) Thanks, good to know. I reckon that you have come across this discussion here, then? http://forum.liquibase.org/#Topic/49382000000322021 Unfortunately, I haven't had much time to have a closer look into DDL in the last months. Teaming up with Liquibase (or Flyway, or both) would be great, of course... 2013/1/27 Witold Szczerba <[email protected]>: > I have developed the following solution: created a new maven project with > class: > > [...] > public class SgnGenerator extends DefaultGenerator { > > @Override > protected String getType(Database db, SchemaDefinition schema, String t, > int p, int s, String u, String defaultType) { > > [...] > > added that project to plugin dependencies and replaced DefaultGenerator with > the one above in configuration section. The separate project was required, > because the code gen is happening before compilation. > > Let me know if there is a better approach :) That sounds like a reasonable option for now. Specifically, as far as Maven is concerned, this is as good as it gets. See also this Stack Overflow question here: http://stackoverflow.com/q/10322155/521799 Be aware though, that I do not give any strong API guarantee within jOOQ codegen, along the lines of semantic versioning: http://semver.org/ This means that your extension may break in future versions of jOOQ. 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/groups/opt_out.
