[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported

["Mamta A. Satoor (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584028#action_12584028 ] 

Mamta A. Satoor commented on DERBY-3320:
----------------------------------------

Committed changes into trunk with revision 643292. At the top level, following describes the changes that went in as 643292.

DERBY-3320 This commit will ensure that if the Collator support does not exist during a territory based database creation, then we will throw an exception saying Collator support does not exist. In case of subsequent boot of a successfully created territory based database, we will check for the Collator support from JVM at the time first collation related operation is run on the database. This can happen if the database recovery needs to be done at the boot time or it can happen after the database has booted and user has issued a SQL which requires Collator support. 

The details of the changes that went into different classes can be seen in the commit comments.

I added a test case for a territory based database creation with a locale for which Collator support does not exist. There is no test case for database recovery and missing Collator support yet. There is also no test for successful territory based database boot but detecting no Collator support when a SQL is issued which requires Collator support.

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