Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <91546297.1207030704771.JavaMail.jira@brutus>
Date: Mon, 31 Mar 2008 23:18:24 -0700 (PDT)
From: "Mamta A. Satoor (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3320) Database creation and boot should
 fail if collation=TERRITORY_BASED and the selected locale is not supported
In-Reply-To: <33047687.1200409595627.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-3320?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1258=
4028#action_12584028 ]=20

Mamta A. Satoor commented on DERBY-3320:
----------------------------------------

Committed changes into trunk with revision 643292. At the top level, follow=
ing describes the changes that went in as 643292.

DERBY-3320 This commit will ensure that if the Collator support does not ex=
ist during a territory based database creation, then we will throw an excep=
tion saying Collator support does not exist. In case of subsequent boot of =
a successfully created territory based database, we will check for the Coll=
ator support from JVM at the time first collation related operation is run =
on the database. This can happen if the database recovery needs to be done =
at the boot time or it can happen after the database has booted and user ha=
s issued a SQL which requires Collator support.=20

The details of the changes that went into different classes can be seen in =
the commit comments.

I added a test case for a territory based database creation with a locale f=
or which Collator support does not exist. There is no test case for databas=
e recovery and missing Collator support yet. There is also no test for succ=
essful territory based database boot but detecting no Collator support when=
 a SQL is issued which requires Collator support.

> Database creation and boot should fail if collation=3DTERRITORY_BASED and=
 the selected locale is not supported
> -------------------------------------------------------------------------=
-----------------------------------
>
>                 Key: DERBY-3320
>                 URL: https://issues.apache.org/jira/browse/DERBY-3320
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.4.0.0
>         Environment: Java ME:
> Product: phoneME Advanced (phoneme_advanced_mr2-b34)
> Profile: Foundation Profile Specification 1.1
> Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386=
 GNU/Linux
>            Reporter: Vemund =C3=98stgaard
>            Assignee: Mamta A. Satoor
>         Attachments: DERBY_3320_Collator_Support_Check_diff_v2.txt, DERBY=
_3320_Collator_Support_Check_stat_v2.txt, DERBY_3320_not_ready_for_commit_d=
iff_v1.txt, DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.j=
ava
>
>
> A problem I've discovered when testing with the phoneME advanced platform=
 is that the collationtests expect other locales than Locale.US to be avail=
able on the platform that is used for the test, and for phoneME advanced (w=
hen compiled as foundation profile) only Locale.US is available. From the j=
dk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US i=
s strictly required:
> public static Locale[] getAvailableLocales()
>     Returns an array of all locales for which the getInstance methods of =
this class can return localized instances. The returned array represents th=
e union of locales supported by the Java runtime and by installed CollatorP=
rovider implementations. It must contain at least a Locale instance equal t=
o Locale.US.
>     Returns:
>         An array of locales for which localized Collator instances are av=
ailable.
> This led me to thinking about how Derby should behave if created/booted w=
ith collation=3DTERRITORY_BASED and territory=3D<some unsupported locale>. =
I'm not sure what the consequences could be if the database is first create=
d on a platform that supports whatever locale is set and later booted with =
one that doesn't, or created on a platform missing support and later booted=
 with one that has. In any case I think it may confuse a user needlessly to=
 see the database boot successfully with his collation setting and later be=
have in a way he does not expect.
> Opinions voiced on the derby-dev list are that both database creation and=
 boot should fail if collation=3DTERRITORY_BASED and the selected locale is=
 not supported.
> If a change like this is implemented, the collationtests should be change=
d to verify correct behavior also if they are executed in an environment we=
re some of the tested locales are not supported.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.