db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Created: (DERBY-3608) Add test cases for missing Collator support during the reboot of a territory based database
Date Tue, 08 Apr 2008 19:21:24 GMT
Add test cases for missing Collator support during the reboot of a territory 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 DERBY-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 be added(also, in order to add the 2 test cases, we need to have a way of removing Collator
support. Vemund Østgaard 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 database, then  crash
it, then make sure that the Collator support for the database'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 code should fail because Collator support does not exist 2)create a territory
based database, then shut it down, then make sure that the Collator support for the database's
locale is not available anymore and then reboot the database. The database reboot should succeed
because it did not need access to Collator. Now, issue a SQL which will do a collation operation
and then collation 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=true;territory=no;collation=TERRITORY_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=1;
--IMPORTANT STEP. Ctrl-C out of ij. ie do not exit but instead, force a database crash by
doing Ctrl-C. Now, remove the Collator support for Norway and 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=true;territory=no;collation=TERRITORY_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 exploring 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 that the above 2 test cases fail in my client as expected.

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

       return (RuleBasedCollator) Collator.getInstance(databaseLocale);

But as we can see, this code obviously can't be checked in. I just did it in my local codeline
to simulate missing Collator support during database recovery or during subsequent database
boot with first SQL with collation support 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 CollatorProvider. This CollatorProvider
could be written in a way that allows you to instrument 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 that
Locale, you just tell it not to by setting a property or something. Basically you could just
tell it to support any Locale, the jre will call a method:

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

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


Mime
View raw message