db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "?ystein Gr?vlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1067) support holdable Scrollable Updatable Resultsets
Date Thu, 16 Mar 2006 09:15:58 GMT
    [ 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


Mime
View raw message