> For backward compatibility (in Connection-based Factory constructor) it's
> possible to wrap Connection to SingleConnectionDataSource for internal
> usage.
That's actually a very good idea. Essentially, org.jooq.Configuration
(implemented by Factory) should have a close() method. If any
operation closes the ResultSet / Statement, it should also close the
Configuration. If the Configuration was initialised with a Connection,
then this is ignored (backwards-compatible). If the Configuration was
initialised with a DataSource, then this should close the jOOQ-managed
Connection ("Spring / DataSource- enabled"). Nice thinking!
> Another advantage of using DataSource in internal jOOQ API - connection can
> be returned to pool as fast as possible.
Yes
> Regarding separation executing and sql rendering concerns.
> I like current jOOQ API and I suppose that much better to write
> factory.select(..).fetch()
> than something like
> executor.fetch(factory.select(...))
> This is one of the reasons why I do not like to use JdbcTemplate with jOOQ.
I do like the current API as well. When adding Executor, I was
thinking of duplicating fetch methods. i.e.:
// this here
factory.select(...).fetch();
// will then internally call this here:
executor.fetch(factory.select(...));
>From a backwards-compatibility perspective, this would be a must-have
requirement anyway. But the advantage of having Executors is the fact
that they can be subclassed and customised much more easily than
Factory / FactoryOperations today, as an Executor will not have to
implement all DSL-specific methods.
Cheers
Lukas
