Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1503010615.1142504220589.JavaMail.jira@ajax>
Date: Thu, 16 Mar 2006 10:17:00 +0000 (GMT)
From: "Andreas Korneliussen (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1067) support holdable Scrollable
 Updatable Resultsets
In-Reply-To: <895488406.1141137101086.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-1067?page=comments#action_12370666 ] 

Andreas Korneliussen commented on DERBY-1067:
---------------------------------------------


>>>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.
> 

That is a typo. I will fix the comment to say: 
"The sequence number for reusable recordIds. As long as this number does not change, recordIds will be stable within the container."

> 
> 
>>>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.
>
Yes, it seems spare1 is a short. Initially the header said there were 20 bytes left. I made use of 8 bytes, and thought that the header was correct from before and withdrew 8 from 20 and got 12. I will fix the comment.

> 
>>>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.
> 
This is part of the HoldabilityTest which was submitted as part of DERBY-1070. It tests that a compress actually takes place. It also does some inserts which ensures that recordIds actually are being reused, and it tests that SUR is not able to update the rows. Without this fix, SUR will incorrectly update one of the inserted rows. So, I think the test is sufficent, it verifies that if a compress is being run, the recordIds are invalidated.


> 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