Hello Aaron, > Just as a teaser, here is the configuration of the new code generator. I'm > not a big fan of XML-based configurations, I prefer DSLs but the API is > public, so writing an XML front-end for the config is just an issue of > someone wanting to scratch this itch.
A DSL contribution is nice, too. If it works well, I can add the XML-parts, which will be required to be able to run code generation through Maven, for instance. That's just like what we have today, where the XML configuration is loaded by GenerationTool or by the Maven plugin, and passed on to the DefaultGenerator. > Here is the config: >From what I've seen so far, most of the configuration does more or less what the current configuration can do? Or am I missing something? I do like the more explicit naming strategy though. There had been a feature request for some time, asking for precisely that. Some remarks: > .renameBooleanColumn( "BLU.ADM_LANGUAGE.IS_DEFAULT", "default" ) That shouldn't be necessary. The boolean type information is available on the ColumnDefinition. If you prefer isXXX() instead of getXXX(), this should be placed elsewhere. In your case, it should be placed into the BluNamingStrategy implementation, not the API > .dialect( SQLDialect.H2 ) I'd prefer if the org.jooq.util.Database implementation is still referenced rather than a SQLDialect, for two reasons 1. Users can override the Database if they want support for an older version. E.g. the default SQLServerDatabase is tested against SQL Server 2008. Someone wanting to generate code for SQL Server 2000 should be able to provide their own custom Database (I've just had this feature request) 2. If we have an intermediate step (e.g. XML), the Database would have to read its data from that XML file. This would then be dialect-independent. Also the JDBCDatabase that I'm planning to add to jooq-meta would be dialect-independent > .schema( "PUBLIC", "BLU" ) Did you plan to keep multi-schema support? Also, I wonder whether object renames should still be possible in two places, i.e. naming strategy AND the overall schema reference. The current generator strategy is a strategy for giving names to Java objects (it would affect what you call the GeneratorFactory) A new "database strategy" that would contain database object renames (such as physical schema renames), and also the include() / exclude() / includeAll() methods, and maybe the type mapping. > .factory( new BluGeneratorFactory( generator.config() ) ) I'm guessing that this will replace what is called DefaultGenerator today, reading the meta data and generating Java classes? Anyway, we should coordinate your goals. Your own personal goals seem to diverge a little from the general jOOQ 3.0 roadmap. Here's the jOOQ 3.0 roadmap: 1. There should be a clean API for jooq-meta. It should be completely independent of the code generator. 2. The 1) jooq-meta API can be implemented in dialect-independent ways, reading meta-information from non-JDBC data sources, such as XML. This can be used to read non-jOOQ XML formats, such as Hibernate's .hbm.xml 3. The jooq-meta API should have a "database strategy", which models today's include/exclude features, database type mappings, database object renames 4. The output produced by 3) "database strategy" is fed into a "JavaGeneratorFactory" or into a "Generator". Today's DefaultGenerator could be a sample implementation thereof 5. An new "XMLGeneratorFactory" could be created to use the feed from 3) "database strategy", to render an XML representation of the schema meta-information. This could then again be fed into 2) 6. Today's "GeneratorStrategy", or what you call the "Naming Strategy" could be called "JavaNamingStrategy", used to map database objects to Java objects. It is specific to 4) "JavaGeneratorFactory". Today's "Naming Strategy" is too low-level, more explicit features would be better. For me, the most important features to add are 2) (new data sources), 5) (new target formats) and maybe 6) (improved Java naming strategies). For you, 6) seems to be the most important improvement, as well as the fact that 4) can be re-implemented in your own way, using Xtend. If we can agree on the roadmap, I can try to devise an API for 1), 3), 4) and 6), and post it on this user group within the next 1-2 weeks. You could then again challenge this API with your requirements Cheers Lukas
