> Joachim, let's have a look at this paragraph: > >> "Oh dear I'll have to learn ALL THAT, that's going to be another >> Hibernate experience where I can't know what I'm actually doing, Jooq >> promised to be easy and in 1:1 correspondence with SQL but it's not >> picking up new features at an alarming rate, where is this whole thing >> headed??" > > What exactly do you mean by "all that"?
On http://jooq.org, Jooq advertises itself as a tool to generate SQL using a fluent API. That's a self-contained task that's small enough to be described in a single sentence. Okay, that task has hidden complexities, the long list of specifically supported databases is a hint in that direction... but it's still a single, well-defined task Now when I take a closer look, I see "extra" features like - code generation - caches - object identity issues - cross-database compatibility - parameter inlining - record mapping - data type conversion - String interning - (there may be more, that was just the result of a quick scan of the user manual) Learning how the various SQL features translate to Jooq's DSL and how to get data into and out of it is already quite a task. Each of the extra features are undisputedly useful - but only to a subset of Jooq users; yet every Jooq user has to learn them all to master Jooq. I'm not advocating removal of these features! But I'm getting alarmed about the rate at which new features are being accepted into Jooq; maybe just a statement about where the limit is would help. There might be another remedy, but it would be a LOT of work: Separating Jooq into several libraries. A DSL core to create AST-like representations of SQL queries. A JDBC part that sends such data structures to JDBC. A reveng part that returns a data model. Most extras could then be recast as separate libraries that can be attached via an API which is (hopefully) focused; the goal would be that it's possible to roll your own extras. I.e. you could write your own code generator, or use the existing default code generator and modify or subclass it to add class prefixes, without the need to ask for a new Jooq feature. Empower the user :-) It's a trade-off, weighing the amount of work to make it happen, more APIs restricting future Jooq evolution, the risk that the whole thing becomes pointless if the APIs evolve into something more complex than the features they support, against the ability to empower the user with a more fine-grained control of what Jooq does. Ultimately, it's not my call to decide that; I'm just pointing out a possible strategy here :-) Regards, Jo -- 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/groups/opt_out.
