db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
Date Tue, 08 Apr 2008 18:19:24 GMT

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


Mime
View raw message