Hi Sergey, > 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.
I'll add the feature on the roadmap. For some release after 2.0, I'm planning to add more runtime configuration for various reasons. This will be treated with https://sourceforge.net/apps/trac/jooq/ticket/910 > If exception translator will not be available through the API, vendorCode > must be accessible from outside (through the nested SQLException, for > example). That'll do for now. > 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 generally don't want jOOQ to get involved with transaction handling and container-specific stuff, that is why jOOQ operates on connections, not data sources... jOOQ cannot decide for the user, when to commit / rollback transactions or close connections that were obtained from a data source. Maybe jOOQ-spring could, but I don't have a good feeling for that yet. > 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. You might want to have a look at the org.jooq.ConfigurationRegistry. That is one way for you to inject connections to queries. This feature is not thoroughly documented yet. >> - 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. I'm sure that oracle JDBC driver classes can deal with a managed (proxied) connection. At least, in a J2EE container, I made good experience with this design. Is this really needed? When would you want to closely couple your application logic to a JDBC implementation? > 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 Wow, that class features methods like isNativeConnectionNecessaryForNativeCallableStatements()... :-) Sergey, I feel that this is going in a wrong direction. jOOQ shouldn't resolve issues on a service-layer level. Maybe I'm getting this wrong, though? Cheers Lukas
