[ http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12450263 ] Suresh Thalamati commented on DERBY-606: ----------------------------------------
I agree with you , it might be trickey to check db versions especially on a readExpternal() call. It would be nice to avoid creating another class. Hopefully some one on the list some has ideas to do that. If you would like to proceed with a new class approach. It would be better to make the new class handle the old behavior . i.e create a new class CompressSpacePageOperation_V10_2 that extends the CompressSpacePageOperation and change the format id for the CompressSpacePageOperation class to a new one. This way it is easier to read the code, and remove the _v0 class later when upgrade is not supported from old version. Looks like assertion check is incorrect in the case you mentioned, please fix it. I would not call the assertion code under debug is in-consistent with insane-builds unless behaviour is different. In debug builds it is normal to do some extra checks , they are useful to get some information when stress tests fail after a few days run. actionCompressSpaceOperation() in LoggableAllocaction has RawTransaction as argument. It would be ok to expose the checkVersion method from logFactory to RawTransaction, Concrete implementation of RawTransaction abstract class , raw/xact/Xact.java already has the logFactory information. I would expect compress operation to work even if there are multiple alloc pages, .may be there is bug some where ; please file a JIRA. Thanks -suresh > SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables > -------------------------------------------------------------------- > > Key: DERBY-606 > URL: http://issues.apache.org/jira/browse/DERBY-606 > Project: Derby > Issue Type: Bug > Components: Store > Affects Versions: 10.1.1.0 > Environment: Java 1.5.0_04 on Windows Server 2003 Web Edition > Reporter: Jeffrey Aguilera > Assigned To: Mayuresh Nirhali > Attachments: A606Test.java > > > SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails with one of the following error > messages when applied to a very large table (>2GB): > Log operation null encounters error writing itself out to the log stream, > this could be caused by an errant log operation or internal log buffer full > due to excessively large log operation. SQLSTATE: XJ001: Java exception: ': > java.io.IOException'. > or > The exception 'java.lang.ArrayIndexOutOfBoundsException' was thrown while > evaluating an expression. SQLSTATE: XJ001: Java exception: ': > java.lang.ArrayIndexOutOfBoundsException'. > In either case, no entry is written to the console log or to derby.log. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
