[
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.
