[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581580#action_12581580 ]
Mamta A. Satoor commented on DERBY-3320: ---------------------------------------- Mike Matrigali had following comment on derby list Do you have some way of creating a database, but then making the Collator not available when you next try to boot the database. I am trying to think of the recovery test case, but need to be able to create the db using a territory based sorting and then the next test case needs to boot the db and find that collator not available. I assume you have the simple test case for creating the db with just picking a territory that does not exist anywhere. > 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 > 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.