Hi Gawie 2017-05-09 19:54 GMT+02:00 <[email protected]>:
> Hi, > > For lack of knowing where to post this type of message. Thanks and well > done. > Thanks for your nice words :) Surely a good place to put this kind of message. > I am by no means a JOOQ expert - but after doing considerable testing and > a small project with it I can definitely commend and recommend JOOQ. It > simply feels natural even considering the Java constraints. Like the way > you do aliasing - to the point where meta-data type tables and polymorphism > can be tackled very differently (simpler and more description in my > opinion) to other DB-technologies. There are a lot of good to say apart > from these mentioned. > That's interesting! I'd like to learn more about what you mean by how aliasing works for you. Do you mean table aliasing and how the aliased table will still have a reference to its columns? > Also, as stated in another thread the only things missing for me are: > 1. Different/better schema selection (as part of the query) > There is the possibility to use the generated schema identifier and dereference tables from there (and even Catalogs in SQL Server). If you go to the generated SchemaImpl (e.g. Public.java), you'll find a static member PUBLIC, which contains instance members for all of your tables (the same ones as in Tables.java). You can then use these references in queries, e.g. DSL.using(configuration) .select(PUBLIC.AUTHOR.FIRST_NAME, PUBLIC.AUTHOR.LAST_NAME) .from(PUBLIC.AUTHOR) .fetch(); This is especially useful for queries that run on several schemas. Is that what you meant? 2. A Kotlin generator would be really sweet > Yes indeed. We will be looking into this when we'll redesign the code generator in jOOQ 4.0: https://github.com/jOOQ/jOOQ/issues/3883 Currently, our experience with the existing JavaGenerator for Scala shows that the existing approach is insufficient. Adding more target language support will make the generator less maintainable. We're definitely open to supporting more target languages, but some preliminary work needs to be done first. > 3. A super fast - near native mapping, mapper to POJO. > Hmm, yes. I just checked, this is available but only when you turn on generation of interfaces using <generate> <interfaces>true</interfaces> </generate> But that's a weird restriction. Surely, when interfaces are present (common to the TableRecord and the POJO), then that should be used in the code generator. But in their absence, we can still generate overloaded from() and into() methods, one for TableRecord and one for the POJO type. I've registered a feature request for this: https://github.com/jOOQ/jOOQ/issues/6199 This will be in jOOQ 3.10. Thanks for pointing this out. If you have any other ideas, do let us know! Cheers, 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.
