Hello Johannes, Thanks for your feedback. I'm replying directly to the user group as these questions are usually of general interest.
> We are using jOOQ in a project @ work mainly for generating SQL statements, > which we execute using Spring's JdbcTemplate. Yes, this has become a very common use-case now. This Stack Overflow question here has more and more traction: http://stackoverflow.com/questions/4474365/jooq-and-spring > 1) All factory implementations require a Connection and NOT a DataSource. > [...] The upcoming version 2.3.0 will feature Sergey Epik's contribution of the FactoryProxy. It is already available on GitHub. The naming is not yet clear, but this has been discussed recently on the user group and been followed with a lot of interest: https://groups.google.com/d/topic/jooq-user/tIwobFOR2iM/discussion > 2) Maybe it would be a good idea to split the FactoryOperstions interface > into two concerns. That was precisely the conclusion to all of these discussions. For historical reasons, the current Factory is both the query builder and query executor object, when in fact the execution part should be refactored out of the Factory. That would allow for many overall improvements, one of which being that a dedicated Executor could operate on a DataSource without relying on Spring's magic, as suggested by Sergey. It's nice to have your feedback on this topic as well. It shows that we're going to be on a good track for jOOQ 3.0 (due in late 2012), when the overall API will be re-worked into what end users really need from jOOQ. Any further input is very welcome! Cheers Lukas 2012/5/3 Johannes Scharf: > Hallo Lukas! > > We are using jOOQ in a project @ work mainly for generating SQL statements, > which we execute using Spring's JdbcTemplate. > > During development we came across the following suggestions for future > improvements: > > 1) All factory implementations require a Connection and NOT a DataSource. > Passing in a DataSource into the constructor would allow for jOOQ to > participate more seamlessly in an enterprise environment. More over it would > be possible to use jOOQ directly with Spring managed transactions and to > reuse the factory instead of creating a new one for each connection at the > beginning of a transaction. > > 2) Maybe it would be a good idea to split the FactoryOperstions interface > into two concerns. One for creating SQL statements and one for executing > them. This would come in handy in situations like our, when someone want's to > use jOOQ mainly as a SQL builder. > > > What do you think? > > > Thank you for your efforts and creating jOOQ! > > Kind regards, > Johannes
