Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1679278055.1205181409794.JavaMail.jira@brutus>
Date: Mon, 10 Mar 2008 13:36:49 -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=3D1257=
7171#action_12577171 ]=20

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

Sorry for the brief comment "making sure that Collator can be instantiated =
for the locale on a give JVM ". Let me elaborate on what I am thinking of d=
oing.

Collator class has a method called getAvailableLocales which returns an arr=
ay of locales which are the union of locales supported by the Java runtime =
and by installed CollatorProvider(a subclass of LocaleServiceProvider) impl=
ementations.=20

Locale class also has a method called getAvailableLocales which returns an =
array of locales which are the union of locales supported by the Java runti=
me and by installed LocaleServiceProvider implementations.

So, it appears that the locale arrary returned from Collator.getAvailableLo=
cales will be a subset of locale array returned by Locale.getAvailableLocal=
es=20

What I was thinking of doing was adding a new method (don't know in which c=
lass at this point) which will go through the arrary returned by Collator.g=
etAvailableLocales and see if the locale requested by the user is included =
in the locale arrary. If not, then throw an exception. I was planning on ca=
lling this method when I find at database create/boot time that user has as=
ked for territory based collation.

After thinking more about it, I think it will be better for us to make the =
new method more generic by going through Locale.getAvailableLocales rather =
than the Collator.getAvailableLocales. And then seee if the locale requeste=
d by the user is inclueded in the locale array. Making the method generic t=
his way will enable us to use it for other Derby functionality that uses th=
e database locale (some of this functionality has been identified by Dan in=
 his earlier comment to this jira entry).

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