Details
Bug
Closed
Major
Description
By using of LIMIT clause check castor the Oracle version. castor expected version like a number, but Oracle 10g returns "10g" version which is a cause of following exception:
java.lang.NumberFormatException: For input string: "10g"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at org.exolab.castor.jdo.DbMetaInfo.compareVersionStrings(DbMetaInfo.java:158)
at org.exolab.castor.jdo.DbMetaInfo.compareDbVersion(DbMetaInfo.java:143)
at org.exolab.castor.jdo.drivers.OracleQueryExpression.isLimitClauseSupported(OracleQueryExpression.java:197)
at org.exolab.castor.jdo.drivers.JDBCQueryExpression.addLimitClause(JDBCQueryExpression.java:282)
at org.exolab.castor.jdo.oql.ParseTreeWalker.addLimitClause(ParseTreeWalker.java:1160)
at org.exolab.castor.jdo.oql.ParseTreeWalker.createQueryExpression(ParseTreeWalker.java:952)
The attached patch fixes recognition of Oracle 10g databases in the class DbMetaInfo. It is implemented by searching for the word "Release" in the full database version string and taking the following number expression. Als fallback solution the old algorithm, which just looks for the first numeric word, is also preserved.
I also inserted two examples of real Oracle product names, like they are returned by the JDBC driver, for better understanding of the algorithm and its problems.