Thank you very much, Samir, for your feedback. 2015-12-30 3:12 GMT+01:00 Samir Faci <[email protected]>:
> *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. > Interesting input about Protobuf. There are indeed language agnostic model formats out there, but using those would drastically limit what is possible in output code. E.g., some things need to be static final, others need to be initialised in constructors, etc. I think it would be hard to implement all the requirements with a non-text-based code generation format. > 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. > The idea is to be able to dump intermediary formats in XML or JSON, which can be loaded back into the code generator in a second go, or which don't have anything to do with code generation at all. This certainly isn't for everybody, but it's a use-case that has been around time and again. If the code generator is to be re-designed, then these use-cases can certainly be covered. *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. > Exactly. And that does happen from time to time. Also: Given that a plugin system might be implemented where users can generate arbitrary artifacts that play with jOOQ (or are independent of jOOQ but have to do with the database meta data), it would be great to provide a better framework to build upon. One use case is a much improved generator for DAOs (or repositories or EJB/CDI artifacts). Another use-case that I have just recently discussed with a customer is to be able to generate JavaScript "types", which model jOOQ's UpdatableRecords on the client and which can be used for serialisation / deserialisation via REST / JSON. We don't want to offer this out-of-the-box (probably). But it would be great if it were easy to do for jOOQ users. *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. > Good point with the 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 [...] > 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. > I perfectly understand, which is why this customisation is already possible. The question is whether this is easy enough, and whether it is complete. Both models are perfectly reasonable: Conversion to adhere to JavaBeans (the default today), which is also what most people do when using JPA, or keeping names as they are reported by the database (the default in jOOQ 4.0, see https://github.com/jOOQ/jOOQ/issues/3570) *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. > I'm glad we talked :) Again, this (the prefixing) can be done already today: - http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy - http://www.jooq.org/doc/latest/manual/code-generation/codegen-matcherstrategy The question is: Is the current functionality sufficient? But I really like the idea of static nested classes. This could be done in the new generated Catalog object that will be available from jOOQ 3.8 onwards. In the case of SQL Server, we would have to go even one step further and add a nested class for catalogs, perhaps. Other than nested classes, the existing mechanism that tables are using could be reused, using a static schema reference and provide instance table references from the schema instance. In any case, we'll address this issue in jOOQ 3.8: https://github.com/jOOQ/jOOQ/issues/4869 Thank you again very much for your useful insight. This already helped a lot getting into the right direction. Best Regards, 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.
