Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <466673682.1207678764750.JavaMail.jira@brutus>
Date: Tue, 8 Apr 2008 11:19: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=
6921#action_12586921 ]=20

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

The only item remaining on this issue is adding 2 test cases. The test case=
s that will be nice to have are 1)create a territory based database, then  =
crash it, then make sure that the Collator support for the database's local=
e is not available anymore and then try to reboot the database, This should=
 make the database go through the recovery and the recovery code should fai=
l because Collator support does not exist 2)create a territory based databa=
se, then shut it down, then make sure that the Collator support for the dat=
abase's locale is not available anymore and then reboot the database. The d=
atabase reboot should succeed because it did not need access to Collator. N=
ow, issue a SQL which will do a collation operation and then collation oper=
ation should fail because Collator is not available.

The manual steps in ij for test case 1 would be=20
connect 'jdbc:derby:c:/dellater/dbTerritory;create=3Dtrue;territory=3Dno;co=
llation=3DTERRITORY_BASED';
create table t1(c11 int, c12 char(4));
create index i1 on t1(c12);
autocommit off;
insert into t1 values (1,'11'),(2,'22');
insert into t1 values (3,'33'),(4,'44');
delete from t1 where c11=3D1;
--IMPORTANT STEP. Ctrl-C out of ij. ie do not exit but instead, force a dat=
abase crash by doing Ctrl-C
Now, remove the Collator support for Norway and restart ij again and follow=
ing reboot of the db should fail
connect 'jdbc:derby:c:/dellater/dbTerritory';

The manual steps in ij for test case 2 would be
connect 'jdbc:derby:c:/dellater/dbTerritory;create=3Dtrue;territory=3Dno;co=
llation=3DTERRITORY_BASED';
create table t1(c11 int, c12 char(4));
insert into t1 values (1,'11'),(2,'22');
exit;
--IMPORTANT STEP Remove the Collator support for Norway and restart ij and =
connect to the database
connect 'jdbc:derby:c:/dellater/dbTerritory';
--following SQL will fail because it requires acces to Collator
select * from t1;


I have not spent the time on Vemund's suggestion about creating and adding =
a custom Collator and removing it. I will go ahead and enter a new jira ent=
ry for exploring custom Collator and then using it to add the 2 test cases =
mentioned above. In the mean time, I did hand tweaked the Derby code to mak=
e sure that the above 2 test cases fail in my client as expected.=20

In both the test cases above, before we restart the ij, I changed DataValue=
FactoryImpl.verifyCollatorSupport code to always throw an exception that Co=
llator is not found. So, my changes in DataValueFactoryImpl.verifyCollatorS=
upport  would look as follows
    =09Locale[] availLocales =3D  Collator.getAvailableLocales();
    =09//Verify that Collator can be instantiated for the given locale.
    =09boolean localeFound =3D false;
    =09for (int i=3D0; i<availLocales.length;i++)
    =09{
    =09=09if (availLocales[i].equals(databaseLocale)) {
    =09=09=09localeFound =3D true;
    =09=09=09break;
    =09=09}
    =09}
    =09if (1=3D=3D1) // THIS IS WHAT i CHANGED. RATHER THAN CHECKING FOR LO=
CALEFOUND, I DO 1=3D=3D1 SO THE EXCEPTION WILL BE THROWN
    =09//if (!localeFound)
=09=09=09throw StandardException.newException(
=09=09=09=09=09SQLState.COLLATOR_NOT_FOUND_FOR_LOCALE,=20
=09=09=09=09=09databaseLocale.toString());
    =09
    =09return (RuleBasedCollator) Collator.getInstance(databaseLocale);

But as we can see, this code obviously can't be checked in. I just did it i=
n my local codeline to simulate missing Collator support during database re=
covery or during subsequent database boot with first SQL with collation sup=
port requirement. I will go ahead and enter a jira entry for a more gracefu=
l way of removing Collator in order for us to have the 2 test cases in our =
junit test suite.

> 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
>             Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0
>
>         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.