Inline comments heavily influenced by my own uses. On Tue, Dec 29, 2015 at 5:27 AM, Lukas Eder <[email protected]> wrote:
> Dear group, > > The jOOQ code generator is one of the biggest assets when using jOOQ. It > allows for referring to your schema in a type safe way, allowing to > leverage IDE auto completion with tables, columns, procedures, etc. > > However, it has grown organically and it thus doesn't allow for the > extensibility that some of you would like. It is time to start thinking > about the future of jOOQ-codegen and jOOQ-meta, to collect ideas for jOOQ > 4.0 in that area, or perhaps even for prior releases. *So, this is a good > time to chime in and discuss potential requirements.* > > The relevant issue is: > https://github.com/jOOQ/jOOQ/issues/3883 > > These are, roughly, the existing features, or existing feature requests: > > *1. Target languages and forms* > > jOOQ currently supports Java and Scala - the most popular languages on the > JVM. Does it make sense to support other languages? Or perhaps even data > formats, like XML? > > This is an interesting topic, but it is also very demanding in terms of > complexity budget. Alternative languages cannot be integration tested as > well as Java without adding substantial effort. > That's fine for me. Closure would be nice, but those are two main JVM languages I'm really interested in. You could leverage things like protobuff to support more languages but honestly probably not worth the effort. Not sure how XML would come into play. My favorite feature of Jooq is that I can point it to a database and generate source of truth so that the code reflects the data. XML (if we're using xml for data definition) would be a step backward, in my view. To each his own though. > > *2. Templating language* > > The code generator currently uses a home-grown templating "language" via a > home-grown, internal, undocumented API. > > In the past, users have suggested using Xtend ( > http://www.eclipse.org/xtend) instead. The advantage of Xtend is that the > template language is built into the Xtend language, and it feels extremely > natural. > > At the time, the idea of integrating Xtend was rejected, because the Xtend > tooling was very Eclipse dependent. This is no longer true, and Xtend is > still a very interesting consideration. > > Alternatively, a programmatic language model (like XJC has) could be > interesting, although it would be very limiting in terms of what's possible > in 1. Target languages. > Aside from ease of use internally, is there any advantage to using any of these. As a simple user of Jooq, I don't think I would need to really interact with the particular templating unless you want to allow the user to override the default auto-gen code. > > *3. Style* > > Programmers like endless discussions about curly braces, indentations, > tabs and spaces. jOOQ currently doesn't embrace this sort of "creativity" > :-) > > It would be great if the generated code style could be influenced in one > way or another, although, this is a rather low priority. > Irrelevant for autogen code IMO. Just follow the standard Oracle standard. > > *4. Generator strategies* > > Most customization is about naming style. Do you want your database > objects in PascalCase? camelCase? UPPER_CASE? lower_case? > > Is this feature sufficient? What's missing here? > I'm not sure if this is a Jooq specific or some library that Jooq is using .. but this does annoy me a good bit. For example, I would have something like //Query Code final ClientListing listing = dslContext.select( CLIENT.ID, CLIENT.NAME, CLIENT.PARENT_ID ) .from(CLIENT) .where(CLIENT.ID.eq(id)) .fetchOneInto(ClientListing.class);//Bean Construction code below. @ConstructorProperties({ "id", "name", "parentId" }) public ClientListing(final long id, final String name, final Long parentId) { this.id = id; this.name = name; this.parentId = parentId; } The fields 'magically' being converted from PARENT_ID to parentId is obnoxious. If the table names are auto-generated as parent_id then my constructor options should match the DB field names. There's something lost in translation where I'm retrieving a field named parent_id but the value intercept by the bean is parentId. Mainly my own petpeave.... > > *5. Disambiguation / compiler "optimisations"* > > jOOQ code compiles almost always. We've thought of many edge-cases where > generated code might cause conflict, e.g. because of naming ambiguity, > invalid identifiers, etc. This is a must-have in any future implementation. > I'm not sure how this could be addressed but I thought I'd point it out. we're using postgres and have multiple schemas, and in certain cases we operate on the same table on multiple schemas. Since we can't import both tables in the same class we end up with these odd inner classes. // Define Jooq Tables from the UI Schema private static class UI { protected static final com.foobar.package.ui.tables.Client CLIENT = com.foobar.package.ui.Tables.CLIENT; } private static class DATA { protected static final com.foobar.package.data.tables.Client CLIENT = com.foobar.package.data.Tables.CLIENT; } If you have a suggestion on a better pattern to use let me know, but it would be nice if the compiler took some override parameter to say add a prefix to the table name. so then I could just naturally export the UI_CLIENT table. > > *6. Custom code* > > Currently, there are a few ad-hoc means of introducing custom code into > generated artefacts. This is mostly done via method extension, which is > rather limiting. > > Recently, there has been quite a bit of criticism about the generated > DAOs, and the fact that they're not really useful for use with Spring or > CDI. That's true, but we don't want to patch them little by little, adding > not well thought through features at this point. > > Instead, YOU should be able to generate DAOs (or repositories, or > services, or session beans) very easily yourself, using jOOQ-meta and a > better jOOQ-codegen. YOU should then be able to publish your jOOQ code > generation "plugins" for reuse in the community. > > Other use-cases are: > > 5.1. Support for additional validation annotations > 5.2. Support for additional Spring or Java EE annotations > 5.3. Support for JPA annotations > 5.4. Support for fluent setters > 5.5. Support for alternative object types (e.g. repositories, services, > etc.) > 5.6. Mutable / immutable POJOs. > 5.7. "Views" expressed in jOOQ (i.e. SQL strings that should generate as > org.jooq.Table) > > In fact, I believe that the core code generation functionality should be > built upon such a plugin system, rather than providing tons of flags to > turn on/off individual features > > *Be a part of it* > > I'm looking forward very much to your feedback, and enthusiast discussion! > > 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. > -- Thank you Samir Faci -- 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.
