Case-insensitivity was a feature which many users wanted. We introduced
this feature a year and a half ago in 10.6.1.0. I think it is reasonable
to assume that this data corruption affects many databases.
Regards,
-Rick
On 9/8/11 11:03 AM, Kristian Waagan wrote:
...
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,
