Thank you very much, Ben, for your insight! 2015-12-30 3:33 GMT+01:00 Ben Hood <[email protected]>:
> 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. > You're right! > 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? > No. Maybe in jOOQ 5.0 :-) But I don't think it will be easy to "transmogrify" jOOQ into other platforms. I'd love to build jOOQ for C++ as it would add great value there, and there's little competition. But C++ templates are a turing complete beast of their own. Knowing how to leverage them for an internal DSL (that works with all compilers) is a lot of work. But these are very valid points. I think that a text-based template language (what we're doing today, in a way) is the way forward because it doesn't close any future doors. > 4. Generator strategies > > Sounds like you're looking for a pluggable strategy abstraction that > can visit DB things and return a string? > We have that, but are they good enough? > > 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. True: https://github.com/jOOQ/jOOQ/issues/4702 > 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. > I see, interesting. This is probably the first time that not the vendor but the user claimed that a bug is really a feature ;-) > 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. > Interesting feedback. So, were you really missing something from the runtime library or from the code generator? The interesting point here is that a better custom code API should also allow for easier workarounds like yours, not just easier additional features. > 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. Well, recent feedback about DAOs have convinced me to finally have this discussion on the list, but there are other items that users like to customise more heavily than DAOs. -- 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.
