Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <293623832.1206376525063.JavaMail.jira@brutus>
Date: Mon, 24 Mar 2008 09:35:25 -0700 (PDT)
From: "Daniel John Debrunner (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=
1593#action_12581593 ]=20

Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------

You can always just make up a locale that doesn't exist, xx_zz

> 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.