Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <2090538916.1205952024974.JavaMail.jira@brutus>
Date: Wed, 19 Mar 2008 11:40: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=
0497#action_12580497 ]=20

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

I might not be understanding the boot handshake correctly but the signature=
 of the boot method in DVF is as follows
public void boot(boolean create, Properties properties) throws StandardExce=
ption=20

BasicDatabase.boot has gotten the Locale required for the db through the fo=
llowing code
=09if (create)
=09{
=09=09if (startParams.getProperty(Property.CREATE_WITH_NO_LOG) =3D=3D null)
=09=09=09startParams.put(Property.CREATE_WITH_NO_LOG, "true");

=09=09String localeID =3D=20
                                                                startParams=
.getProperty(org.apache.derby.iapi.reference.Attribute.TERRITORY);

=09=09if (localeID =3D=3D null) {
=09=09=09localeID =3D Locale.getDefault().toString();
=09=09}
=09=09databaseLocale =3D monitor.setLocale(startParams, localeID);
=09} else {
=09=09databaseLocale =3D monitor.getLocale(this);
=09}
And then BasicDatabase.boot boots DVF and calls DVF.setLocale so that it ca=
n pass the locale object that it has determined to DVF. It looks like there=
 is no way to pass that locale info through the boot machinery that we alre=
ady have in place. So, if we want DVF.boot to do the Collator checking, it =
will have to get its hand on locale in it's boot method by going through co=
de similar to BasicDatabase.boot (copied above). This seems fine to me beca=
use then everything related to boot is in boot method of the DVF and it doe=
s not have to wait for DVF.setLocale to get it's locale set correctly. If w=
e do decide to go this path, then we can remove DVF.setLocal from BasicData=
base.boot and do the locale setting in the DVF boot method.

> 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_not_ready_for_commit_diff_v1.txt, DERBY_3=
320_not_ready_for_commit_stat_v1.txt, 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.