db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3608) Add test cases for missing Collator support during the reboot of a territory based database
Date Tue, 30 Jun 2009 23:38:48 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dag H. Wanvik updated DERBY-3608:
---------------------------------

    Issue Type: Improvement  (was: Test)

> 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: Improvement
>          Components: Test
>    Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.1.1
>            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