Just completing Samir's excellent answer here: There's the possibility to turn off most of the generation of the classes you've seen. Samir's link also describes how to turn on/off the various artefacts. If in doubt, just leave them there - they won't really bother you (and prove useful occasionally), e.g. if you don't have any Keys, you cannot profit from:
- UpdatableRecords, as Key information is required for those - Meta data navigation, in case you ever need this Here's again the link: https://www.jooq.org/doc/latest/manual/code-generation Some more comments inline 2017-04-05 18:18 GMT+02:00 Anto Aravinth <[email protected]>: > 1. DefaultCatalog, > DefaultCatalog is there in all databases that do not support any explicit catalog (currently all but SQL Server). But you don't need to worry about this > Sequences, Tables > These are helpful utilities, e.g. you can static import Tables.* to have all table references available to your DAO logic. That's quite useful. > There were SQLDialect for specific POSTGRES version like 9.4 etc, but what > version does SQLDIalect.POSTGRES refers? > If a SQLDialect family (e.g. POSTGRES) has different versioned dialects (e.g. POSTGRES_9_4), then the family will always be equivalent to the *latest* version available from jOOQ. This is mostly irrelevant as there are few differences in the jOOQ implementation that depend on the dialect version (with the exception of Oracle and SQL Server's OFFSET .. LIMIT support), mostly these versions are useful to document API If you want to stay on the safe side, you can simply use the latest available version that is less or equal to your server version. 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.
