About
1. code generation: would be great have more options about pojo generation. I.e. generate json-schema / json of tables or xml/xsd of tables. In some situations could be nice. 2. something more about xml /xpath /json queries type safeting. I don't know really how but of course db dependent... Il giorno martedì 29 dicembre 2015 12:27:46 UTC+1, Lukas Eder ha scritto: > > 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.
