[ http://issues.apache.org/jira/browse/DERBY-1067?page=comments#action_12370660 ]
Øystein Grøvlen commented on DERBY-1067: ---------------------------------------- Andreas Korneliussen (JIRA) wrote: >> Øystein Grøvlen commented on DERBY-1067: >> ---------------------------------------- >> >> 2. It seems to me that positionOnRowLocation() can return false in two >> cases: >> 1) The row location is no longer valid >> 2) The record at this location has been deleted >> Does not a caller need to distinguish between these two cases? >> > > No. In order for a RowLocation to be invalidated,the row has to be > deleted, either as part of a compress (delete+insert) or as part of > delete+purge. The caller does not need to distinguish between these > two cases. I understand that there are two ways for a RowLocation to become invalid: 1. On the first repositioning after a compress. 2. Repositioning on a deleted&purged row. Will the holdable cursor be invalidated in both cases, or will one be able to continue to the next record in the second case? > >> 3. I suggest to use something even more generic than >> reusableRecordIdSequenceNumber. How about recordIdVersion or >> something like that? I agree that what we worry about here is >> reuse of record ids, but I think this mechanism could be used for >> other purposes too. >> > > I think I will leave it as is, since I have previously been asked to > link this with reusable record ids. However, I do not mind that > anyone uses this mechanism for something else, and as part of that > issue renames it to something else, like recordIdVersion. You describe the new header field as "The sequence number for reusable sequence number." For someone who is just looking at FileContainer and not concerned about your specific use of this field, this does not make much sense. A meaningful concept for FileContainer is "As long as this number does not change, RecordIds will be stable". This will also cover those concerned with records being moved, as well as those only concerned by reuse of RecordIds. >> 6. FileContainer header: >> a) When looking at the list of fields, it seems like there will >> be only 10 bytes of spare space left. > > One long field (8 bytes) + one integer (4 bytes), should be 12. > Do not see how it would only be 10 bytes left. According to the comment spare1 is only 2 bytes. >> 7. Unit test: >> a) I think it would also be good with a test that does next() >> after a compress and verifies that it is positioned at the >> correct row. (Or maybe this is already part of the SUR >> testsuite?) > Added. New additions look very good. However, I would be much more comforted with a test where compress actually does something. That is, tests where records have been deleted. Maybe this is already part of the SUR testsuite? We should also have tests that reposition holdable cursors on deleted records. > support holdable Scrollable Updatable Resultsets > ------------------------------------------------ > > Key: DERBY-1067 > URL: http://issues.apache.org/jira/browse/DERBY-1067 > Project: Derby > Type: Sub-task > Reporter: Andreas Korneliussen > Assignee: Andreas Korneliussen > Attachments: DERBY-1067.diff, DERBY-1067.stat, DERBY-1067v2.diff, > DERBY-1067v2.stat, DERBY-1067v3.diff, derbyall_report.txt > -- 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
