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.
