Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1527417810.1207682484359.JavaMail.jira@brutus>
Date: Tue, 8 Apr 2008 12:21:24 -0700 (PDT)
From: "Mamta A. Satoor (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Created: (DERBY-3608) Add test cases for missing Collator
 support during the reboot of a territory based database
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Add test cases for missing Collator support during the reboot of a territor=
y based database
---------------------------------------------------------------------------=
----------------

                 Key: DERBY-3608
                 URL: https://issues.apache.org/jira/browse/DERBY-3608
             Project: Derby
          Issue Type: Test
          Components: Test
    Affects Versions: 10.3.2.2, 10.4.0.0, 10.5.0.0
            Reporter: Mamta A. Satoor


Changes into Derby engine for missing Collator support went in as part of D=
ERBY-3320. A test case was added in DERBY-3320 if the required Collator was=
 not available during the database create time. But it will be nice to add =
2 more test cases to cover the reboot of the territory based database. I am=
 copying following from DERBY-3320 which explains what test cases need to b=
e added(also, in order to add the 2 test cases, we need to have a way of re=
moving Collator support. Vemund =C3=98stgaard had a suggestion on how that =
can be done. I will copy his suggestion towards the end of this field.

*******************************Copied from DERBY-3320**********************=
****
The test cases that will be nice to have are 1)create a territory based dat=
abase, then  crash it, then make sure that the Collator support for the dat=
abase's locale is not available anymore and then try to reboot the database=
, This should make the database go through the recovery and the recovery co=
de should fail because Collator support does not exist 2)create a territory=
 based database, then shut it down, then make sure that the Collator suppor=
t for the database's locale is not available anymore and then reboot the da=
tabase. The database reboot should succeed because it did not need access t=
o Collator. Now, issue a SQL which will do a collation operation and then c=
ollation operation should fail because Collator is not available.

The manual steps in ij for test case 1 would be
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 an=
d restart ij again and following 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. This jira entry can be used for explorin=
g custom Collator code and then using it to add the 2 test cases mentioned =
above. In the mean time, I did hand tweaked the Derby code to make sure tha=
t the above 2 test cases fail in my client as expected.

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
       Locale[] availLocales =3D  Collator.getAvailableLocales();
       //Verify that Collator can be instantiated for the given locale.
       boolean localeFound =3D false;
       for (int i=3D0; i<availLocales.length;i++)
       {
               if (availLocales[i].equals(databaseLocale)) {
                       localeFound =3D true;
                       break;
               }
       }
       if (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
       //if (!localeFound)
                       throw StandardException.newException(
                                       SQLState.COLLATOR_NOT_FOUND_FOR_LOCA=
LE,
                                       databaseLocale.toString());

       return (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.
*******************************End of copy from DERBY-3320*****************=
****


*****************Vemund's suggestion copied from DERBY-3320****************=
**********
What comes to mind is that I think you could write your own CollatorProvide=
r. This CollatorProvider could be written in a way that allows you to instr=
ument it to behave the way you want. This CollatorProvider would extend the=
 support in the jdk/jre with some dummy Collator for a made up Locale when =
you want it to. Then, when you want it to no longer provide support for tha=
t Locale, you just tell it not to by setting a property or something. Basic=
ally you could just tell it to support any Locale, the jre will call a meth=
od:

public abstract Collator getInstance(Locale locale)

that you implement yourself in your CollatorProvider.

The javadoc for LocaleServiceProvider says a bit about how to package such =
an extension. I don't know if this is a feasible path but it might be worth=
 looking into.
*******************************End of copy from DERBY-3320*****************=
****

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