By the way, Sergey, Do you think the idea of a session would help you more? I imagine that when the concept of a session is introduced in jOOQ, it'll be easier to abstract transaction handling and dealing with data sources.
I could imagine that the Factory will continue to operate on connections directly, whereas a Session could also provide connections to executed queries using the existing Attachable API. If that is done, then a Session could manage the connection it gets from a data source. Read more in this thread: https://groups.google.com/forum/#!topic/jooq-user/s6Bqgz_81Yw Cheers Lukas 2011/11/5 Sergey Epik <[email protected]>: > Hello Lukas, > > > On Fri, Nov 4, 2011 at 6:00 PM, Lukas Eder <[email protected]> wrote: > >> - The unchecked DataAccessException is now always formally declared in >> method signatures, and documented in Javadocs. I think that's cleaner. >> But I really do like the fact of it being unchecked. >> - I moved the relevant Factory Javadoc up to FactoryOperations (not >> sure about the name of that interface yet) >> - Factory.fetch(ResultSet) is now also declared in FactoryOperations >> (might've been forgotten) >> - I removed the exception translator type for now, replacing it by a >> static package-private method in JooqUtil, as this is incomplete. The >> final API might differ, so I prefer not to change the API for now. >> Maybe there is no need to expose that API. >> - I changed all relevant methods in your Spring FactoryProxy (class >> renamed) to being final. I tend to prefer that. > > Thank you! > > Regarding exception translator. It may be useful to set custom translator, > additionally to dialect-specific default translator. > For example, to handle exceptions from PL/SQL package (to handle > application-specific SQLException.vendorCode values). > It was assumed that DataAccessException will be abstract and exception > translator will be necessary to instantiate proper successor. > Anyway this feature is optional. > If exception translator will not be available through the API, vendorCode > must be accessible from outside (through the nested SQLException, for > example). > > It would be great to see JooQFactoryProxy as a temporary workaround. > Is it possible to make Factory connectionless, i.e. replace getConnection() > in Configuration/Factory with getDataSource()? > I mean getting connection at the beginning of try/catch block (places, where > JooqUtil.translate is now called) and closing in finally block. > Data source usually transaction-manager aware, so we will receive the same > connection during transaction (transaction manager binds connection to > thread). > For simple cases single-connection datasource can be used (just wrapper over > single connection). SingleConnectionDataSource is a good example. > > Regarding FactoryOperations and DataAccessException, I am also not sure that > these names are good. > >> >> And I have some questions: >> >> - How can I keep OSGI export/import instructions in synch with the >> rest of the pom.xml's maven dependencies? > > I suppose plugin cares about dependencies. > >> >> - What is the NativeJdbcExtractor useful for? Can you show me concrete >> examples? > > If JDBC connection is received from data source (pooled), it almost always > is a proxy. NativeJdbcExtractor tries to extract native jdbc connection from > proxy. > I guess that org.jooq.util.oracle.OracleUtils requres native oracle > connection. > JdbcTemplate, for example, always tries to resolve native connection and > execute query using this connection. > There are several implementations of this interface (one per data source > type): > http://static.springsource.org/spring/docs/3.0.6.RELEASE/javadoc-api/org/springframework/jdbc/support/nativejdbc/NativeJdbcExtractor.html > > Best regards, > Sergey >
