[ https://forge.continuent.org/jira/browse/SEQUOIA-1029?page=comments#action_14284 ]
Emmanuel Cecchet commented on SEQUOIA-1029: ------------------------------------------- Actually LIKE respects the database encoding whereas = does a strict binary comparison (this is why you may not see it fail depending on the encoding). So LIKE should be preferred for more portability. I guess the speed will depend on the implementation. As Stephane suggested it is also possible to externalize the string comparison operator in the configuration file. But as COMMIT and ROLLBACK are not patterns with %, the speed should just depend on the encoding used by the database and the optimizer should take care of it. > Recovery Log consistency check fails using Derby as the database > ---------------------------------------------------------------- > > Key: SEQUOIA-1029 > URL: https://forge.continuent.org/jira/browse/SEQUOIA-1029 > Project: Sequoia > Type: Bug > Components: Recovery Log > Versions: sequoia 2.10.11 > Environment: JAVA 1.5.0_13 > Solaris 10 SPARC > Derby 10.3.2.1 > Reporter: Nick Smith > Assignee: Emmanuel Cecchet > Fix For: sequoia 2.10.10 > > Original Estimate: 3 hours > Remaining: 3 hours > > The Recovery Log consistency check fails when using Derby as the database. > The consistency check SQL should use 'LIKE' instead of '=' as this databases > databases have different ways to interpret '=' on Strings. > i.e. the SQL in > org.continuent.sequoia.controller.recoverylog.RecoveryLog.checkRecoveryLogConsistency() > should be : > stmt = getDatabaseConnection().prepareStatement( > "SELECT * FROM " + getLogTableName() + " WHERE " > + getLogTableSqlColumnName() + " LIKE ? AND " > + "transaction_id not in (SELECT transaction_id" + " FROM " > + getLogTableName() + " WHERE " + getLogTableSqlColumnName() > + " LIKE ? OR " + getLogTableSqlColumnName() + " LIKE ?) "); > instead of : > stmt = getDatabaseConnection().prepareStatement( > "SELECT * FROM " + getLogTableName() + " WHERE " > + getLogTableSqlColumnName() + " LIKE ? AND " > + "transaction_id not in (SELECT transaction_id" + " FROM " > + getLogTableName() + " WHERE " + getLogTableSqlColumnName() > + " = ? OR " + getLogTableSqlColumnName() + " = ?) "); > stmt.setString(1, BEGIN + "%"); > stmt.setString(2, COMMIT); > stmt.setString(3, ROLLBACK); > Please Note! > Derby also seems to unbearably slow performing the above SQL (at least with > my recovery log configuration). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://forge.continuent.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
