Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 22 Oct 2012 15:02:12 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <1717597096.9979.1350918132713.JavaMail.jiratomcat@arcas>
In-Reply-To: <1911693874.9962.1350917652313.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (DERBY-5959) Territory-based collation is not
 robust against changes in the collation rules
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-5959?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1348=
1411#comment-13481411 ]=20

Knut Anders Hatlen commented on DERBY-5959:
-------------------------------------------

Example where this would lead to inconsistencies:

Create a database using Java 5:

connect 'jdbc:derby:tr-db;territory=3Dtr_TR;collation=3DTERRITORY_BASED;cre=
ate=3Dtrue';
create table t(c char(2));
insert into t values '=C4=B1a', 'Ia', 'ia', '=C4=B0a', '=C4=B1b', 'Ib', 'ib=
', '=C4=B0b';
create unique index idx on t(c);

Then update the database using Java 6 or later:

connect 'jdbc:derby:tr-db';
insert into t values '=C4=B1b';
select * from t;

The result of the SELECT statement is:

ij> select * from t;
C  =20
----
=C4=B1a =20
Ia =20
=C4=B1b =20
ia =20
=C4=B0a =20
=C4=B1b =20
Ib =20
ib =20
=C4=B0b =20

9 rows selected

The value '=C4=B1b' appears twice, even though there is a unique index on t=
he column.
               =20
> Territory-based collation is not robust against changes in the collation =
rules
> -------------------------------------------------------------------------=
-----
>
>                 Key: DERBY-5959
>                 URL: https://issues.apache.org/jira/browse/DERBY-5959
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.10.0.0
>            Reporter: Knut Anders Hatlen
>
> When accessing a database with territory-based collation, Derby will use =
the collation rules of the collator returned by Collator.getInstance(databa=
seLocale). However, there is no guarantee that those rules are consistent a=
cross different JVM vendors and versions. This means that the ordering coul=
d vary, and inconsistencies could sneak into the indexes.
> One example is that Oracle's JDK changed the collation rules for Turkish =
between Java 5 and Java 6, so if you run the following script
> connect 'jdbc:derby:memory:db;territory=3Dtr_TR;collation=3DTERRITORY_BAS=
ED;create=3Dtrue';
> create table t(c char(2));
> insert into t values '=C4=B1a', 'Ia', 'ia', '=C4=B0a', '=C4=B1b', 'Ib', '=
ib', '=C4=B0b';
> select * from t order by c;
> you'll get different results on Java 5 and on Java 6 and later.
> Java 5 will order the results like this:
> ij> select * from t order by c;
> C  =20
> ----
> =C4=B1a =20
> Ia =20
> ia =20
> =C4=B0a =20
> =C4=B1b =20
> Ib =20
> ib =20
> =C4=B0b =20
> 8 rows selected
> Java 6 and later order them like this like this:
> ij> select * from t order by c;
> C  =20
> ----
> =C4=B1a =20
> Ia =20
> =C4=B1b =20
> Ib =20
> ia =20
> =C4=B0a =20
> ib =20
> =C4=B0b =20
> 8 rows selected

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira