Hi Gili, I will expose some of the methods you mentioned in your DatabaseConnection directly from the Factory. This will be tracked as #1521: https://sourceforge.net/apps/trac/jooq/ticket/1521
These methods include transaction-related methods on the JDBC Connection interface: - commit() - rollback() - rollback(Savepoint) - setSavepoint() - setSavepoint(String) - releaseSavepoint(Savepoint) - setAutoCommit(boolean) - getAutoCommit() - setHoldability(int) - getHoldability() - setTransactionIsolation(int) - getTransactionIsolation() This will be available in jOOQ 2.4.0. Most of these methods are useful only when Factory wraps a Connection, not a DataSource. Potential implementation for use with DataSources can be further discussed and added in a future release. Cheers Lukas 2012/6/13 cowwoc <[email protected]>: > Hi digulla, > > Factory wouldn't need to extend Connection, it could simply provide the > same method signatures and delegate to the underlying connection. Take a > look at the attached class that does this. Ideally this functionality should > be built into Factory instead of having to wrap it with a second class. > > Gili > > > On 13/06/2012 1:48 PM, digulla wrote: > > Am Montag, 11. Juni 2012 21:16:56 UTC+2 schrieb Gili Tzabari: > >> What about committing transactions? If I have to invoke >> Factory.getConnection().commit() after the JOOQ code I still end up having >> to catch both DataAccessException and SQLException. Couldn't >> Factory.getConnection() return a wrapper object? > > > Not really. There is no sane way to extend most JDBC classes in Java code - > compilation will break with different versions of Java, for example. > > I would prefer if "new Factory()" would accept a wrapper object instead; > that would ease the migration path to new versions of JDBC and make the API > cleaner. If this wrapper would have this API: > > getConnection() // get underlying JDBC connection > commit() // commit the current transaction > rollback() // ... > > then such things would be possible. > >
