db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: 10.8.2 coming even closer
Date Thu, 08 Sep 2011 18:47:22 GMT
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,


Mime
View raw message