[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586921#action_12586921
]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
The only item remaining on this issue is adding 2 test cases. 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. I will go ahead and enter a new jira entry for
exploring custom Collator 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. I will go ahead and enter a jira entry for a more graceful way of
removing Collator in order for us to have the 2 test cases in our junit test
suite.
> Database creation and boot should fail if collation=TERRITORY_BASED and the
> selected locale is not supported
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3320
> URL: https://issues.apache.org/jira/browse/DERBY-3320
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.4.0.0
> Environment: Java ME:
> Product: phoneME Advanced (phoneme_advanced_mr2-b34)
> Profile: Foundation Profile Specification 1.1
> Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386
> GNU/Linux
> Reporter: Vemund Østgaard
> Assignee: Mamta A. Satoor
> Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0
>
> Attachments: DERBY_3320_Collator_Support_Check_diff_v2.txt,
> DERBY_3320_Collator_Support_Check_stat_v2.txt,
> DERBY_3320_not_ready_for_commit_diff_v1.txt,
> DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java
>
>
> A problem I've discovered when testing with the phoneME advanced platform is
> that the collationtests expect other locales than Locale.US to be available
> on the platform that is used for the test, and for phoneME advanced (when
> compiled as foundation profile) only Locale.US is available. From the jdk1.6
> javadoc of Collator.getAvailableLocales() I see that only Locale.US is
> strictly required:
> public static Locale[] getAvailableLocales()
> Returns an array of all locales for which the getInstance methods of this
> class can return localized instances. The returned array represents the union
> of locales supported by the Java runtime and by installed CollatorProvider
> implementations. It must contain at least a Locale instance equal to
> Locale.US.
> Returns:
> An array of locales for which localized Collator instances are
> available.
> This led me to thinking about how Derby should behave if created/booted with
> collation=TERRITORY_BASED and territory=<some unsupported locale>. I'm not
> sure what the consequences could be if the database is first created on a
> platform that supports whatever locale is set and later booted with one that
> doesn't, or created on a platform missing support and later booted with one
> that has. In any case I think it may confuse a user needlessly to see the
> database boot successfully with his collation setting and later behave in a
> way he does not expect.
> Opinions voiced on the derby-dev list are that both database creation and
> boot should fail if collation=TERRITORY_BASED and the selected locale is not
> supported.
> If a change like this is implemented, the collationtests should be changed to
> verify correct behavior also if they are executed in an environment were some
> of the tested locales are not supported.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
