Hi Lukas, Please find comments about your listed items inline.
On Tue, Dec 29, 2015 at 11:27 AM, Lukas Eder <[email protected]> wrote: > 1. Target languages and forms > 2. Tempting language I think that (1) and (2) are intrinsically linked and hence are difficult to treat separately. For one thing, the code generator needs to not only produce source that will compile or interpret given an arbitrary compiler/interpreter, it also needs to conform to an ABI for the runtime library of the given target language. For different language frontons on the same platform (e.g. Scala and Java) you can re-target more easily because you could re-use an single JOOQ runtime library. Once you start targeting non-JVM stuff, then you either need port the runtime or somehow transmogrify it (either by static code translation or by some kind of foreign function invocation back to the original JVM runtime). You could take a half way house approach and define the semantics of the ABI, but then, how would be able to verify that a given implementation is protocol compliant. Sounds like you'd need a big test suite. And then once you have that, you still need to make sure your templates generate valid front end code, both for the target language and the backend API. That all said, maybe I've completely misunderstood JOOQ. In my mind JOOQ essentially provides type safe SQL access, provided you are using JDBC. Are there any non-JDBC JOOQ backends that can help invalidate my assumption? > 3. Style Code style for generated code is of lesser importance to me. > 4. Generator strategies Sounds like you're looking for a pluggable strategy abstraction that can visit DB things and return a string? > 5. Disambiguation / compiler "optimizations" I've run into naming conflicts with legacy schemas before (e.g. DDL with column names that differ just by case sensitivity alone, for which JOOQ has produced non-compiling code. That said, I was actually glad that JOOQ blew up in this way, since it provided an easy check that something was very wrong with the schema that we were hacking into. In this situation I started by using the code generator config to help me avoid the troublesome table, so in the first instance there was no JOOQ access to this table. Then when I needed to read/write to/from it, I created a view on the broken table that JOOQ would compile against. > 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. I've had to hook into the JavaGenerator class to override a method to get the generator to play ball with the custom type binding I had cooked up. But IMHO this could have been circumvented by allowing application level access to the SQL type indexer in the compiler, which is currently sealed off to members of the general public. So I ended up hacking the generator just to achieve the effect of registering a custom type. I think maybe most of the questions about custom code relate to DAO construction? If so, I'll have to back out of the discussion because I haven't used the DAO side of JOOQ. Cheers, Ben -- 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.
