when using JNDI, will try to discover the real adapter. #25
Conversation
and centralize the special handling of the adapter for Sqlserver so we don't get error when using transaction.
…re block would be nil
…nt which cannot be casted as a OracleStatement. Need to unwrap it first.
DataMapper expects Sqlite adapter, but DataObject expects Sqlite3. There is code in dm-sqlite-adapter to change the adapter from sqlite to sqlite3, and the dm-do-adapter to create URI using adapter instead of scheme…. but that breaks JNDI case, when we want to scheme to stay 'java', but adapter to be whatever the underlying adapter is. consolidated more of the logic that maps DM constants to DO constants and changing DriverDefinition's verifyScheme to check for both scheme and jdbcScheme (in the case of 'sqlite' vs. 'sqlite3').
Avoided references to OraclePreparedStatement completely. Apparently there are multiple definition of the class, and it moves around.
ghost
assigned 
|
@patcheng @mkristian Sorry for only just following up on this patch. The JNDI part looks right. I'm just trying to understand the Oracle JDBC driver changes. Would it be possible to have that as a separate PR? (wdyt @pietia) |
|
@myabc +1 for separate patches |
|
@patcheng your commits are really interesting! Did you check if your version still works with other Oracle drivers? |
|
I never saw the second set of patches - should have merged the JNDI commit immediately ;). the DBCP commit is very specific code - tomcat related. |
|
@pietia It should. The problem is with the newer version of Oracle JDBC driver, they changed the package name of the OraclePrepareStatement, so there is no way to have a class file that works with the older and newer version. That's why I had to do reflection. |
|
@mkristian yeah, I am not happy with the DBCP-specific code either. But when running under Tomcat, I cannot find another way to get to Oracle's PrepareStatement class. |
and centralize the special handling of the adapter for Sqlserver so we don't get error when using transaction.