On 08.09.11 19:22, Myrna van Lunteren wrote:
Hi,
I will probably not do much work preparing for the release on Friday
or over the weekend, but still intend to build a release on Monday,
Sept 12, so checking now on the various things I think are going on
that might make it:
https://issues.apache.org/jira/browse/DERBY-4275 (Knut):
On Sep 1, Knut wrote: "I think [backport] should be safe. I'll have a
look. I'll probably resolve the issue again now, since the original
fix did improve the situation, and file a new report for the remaining
issue revealed by the regression test case."
It looks like a fix was commited on Sep 2 for the issue revealed by
the test case - so this issue is now complete and can be closed?
https://issues.apache.org/jira/browse/DERBY-5236 (Knut): On Sep 1,
Knut wrote "I'm not sure if a complete fix will be in place for 10.8.2
(or if the complete fix will be suitable for backport since it may
involve protocol changes), but I intend to backport as much as
possible of the code in this issue."
current status: the following commits went into trunk: 1104365,
1163131, 1164495, and a patch is ready for review. No backports to
10.8 yet.
I'm still hoping this will make it into 10.8, but won't wait the
release for it.
https://issues.apache.org/jira/browse/DERBY-5347 (Kathey): Still
working on this, I think.
https://issues.apache.org/jira/browse/DERBY-5363 (Dag): not happening
for 10.8, looks like. (patch ready for review, gathering info from
user list).
https://issues.apache.org/jira/browse/DERBY-5398 (Rick submitted a
patch for review, would be good to get it in).
https://issues.apache.org/jira/browse/DERBY-5404 (Kim): fix was
committed to trunk (being backported?)
Please let me know of any additions, corrections...
Hi Myrna,
I'm having trouble with DERBY-5367 [1].
When trying to implement the simplest possible fix, by replacing one
store call with another, I get errors in some of the tests - more
specifically during transaction rollback. I have one more idea for a fix
to try out, but I fear the associated performance implications may be
too severe. I'll try figure that out today, worst case tomorrow.
I believe the bug is a data corruption bug, since the wrong field value
is stored in the index. To hit it, you have to use a collation, insert
value A, delete value A, and then insert value A' before the deleted row
has been reclaimed. The point here is that values A and A' are
considered equal by the collation, although the string values are
different. Derby currently updates the row location, but fails to update
the field value stored in the index.
The simplest example is case insensitive collations (or strengths), as
was the case in DERBY-5367, where 'Test' and 'test' are considered
equal. If 'Test' was inserted first, a select query using the index
would incorrectly return 'Test' whereas a select query not using the
index would return the correct value 'test'.
If anyone believe they have enough time to produce a working fix before
Monday, or to figure out what I'm doing wrong, feel free to assign
yourself to the issue.
Regards,
--
Kristian
[1] https://issues.apache.org/jira/browse/DERBY-5367
>
Thx,
Myrna
