Hi, since we have a special chance to have our say :) I would like to mention about the thing which makes a little trouble now. Let's say I have a class WalletId. It's just a wrapper around String, VARCHAR in SQL. The trouble is, if I want to do a custom mapping for some columns in tables to use WalletId, I have to split the project to have two artifacts. So, instead of one POM, we need now 3: one for the WalletId class, second for the rest of the project and third, a parent for those two. In Microservices, when all the modules are really small, it is even more annoying.
Question is: is it possible to mix the process of code generation with the project's compilation phase, so we could get the auto-generated code to use the types from that module itself? Other things on my hypothetical wish list would be to support non-JDBC drivers. As we know the JDBC is a blocking API, but there are alternative drivers for some databases using async techniques. There is a lack of standardization in this area, but in my imaginary, perfect world :) the projects like jOOQ could try to change the JVM world in this area! OK, I was just thinking loudly :) I won't even mention support for Clojure. Such a feature would cost a lot of time and I guess it would be doable by a 3rd parties if such a desire would emerge. Thanks, Witold Szczerba On Tue, Dec 29, 2015 at 12:27 PM, 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. > > *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. > > *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. > > *4. Generator strategies* > > Most customisation 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? > > *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. > > *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. > -- 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.
