You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mamta A. Satoor (JIRA)" <ji...@apache.org> on 2008/04/08 21:21:24 UTC
[jira] Created: (DERBY-3608) Add test cases for missing Collator
support during the reboot of a territory based database
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.
[jira] Updated: (DERBY-3608) Add test cases for missing Collator
support during the reboot of a territory based database
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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.