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] Updated: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
Date Fri, 21 Mar 2008 20:33:24 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mamta A. Satoor updated DERBY-3320:
-----------------------------------

    Attachment: DERBY_3320_Collator_Support_Check_stat_v2.txt
                DERBY_3320_Collator_Support_Check_diff_v2.txt

I am attaching a patch DERBY_3320_Collator_Support_Check_diff_v2.txt which will make sure
during the database create time that Collator support is available from the JVM otherwise
an exception will be thrown. As for the subsequent boot times, the Collator support from the
JVM will be checked the first time there is a need to access Collator functionality. This
may or may not be at the database boot time. The first access to Collator object can happen
under 2 scenarios 1)during database boot time because Store has to recover the database or
2)if user exectues a SQL which requires territory based collation.

In order to do the check for Collator support during database create time, I had to add code
in DataValueFactoryImpl.boot to look at the collation attribute on the JDBC url, verify it's
value and see if user has requested territory based collation. If yes, then verify that JVM
supports the Collator for the database's locale. Because the attribute value validation happens
here in DVF.boot, we do not need to do the value validation again in DataDictionaryImpl.boot
and hence I removed the collation attribute value validation from DataDictionaryImpl.boot.

Also, BasicDatabase.boot does not have to make special call to DVF.setLocal to set the locale
on DVF because it now happens in DVF.boot method. This makes the code fit more into the existing
boot machinery rather than relying on special calls like DVF.setLocale.

The Collator support is being done in a new method DVF.verifyCollatorSupport and this method
gets called both during database create time and during subsequent database boot  times, it
gets called when the Collator object is accessed for the first time.

I have added a new error message for unavailability of Collator and the message reads as follows
Collator support not available from the JVM for the database's locale '{0}'.
If anyone has any other suggestion for the error message, please let me know.

Lastly, I could use some help in coming up with test cases for database recovery such that
the Collator support is available during create time, then the database is crashed and during
next boot time, store will try to recover the database but should run into the situation that
the Collator support is no more available. This kind of test case will make sure that Collator
unavailability exception is thrown properly to the user even in case of store recovery.

As for the non-recovery database case, I think we have test cases already(CollationTest and
CollationTest2) in place which run into problem on phoneME. With revision 618507, we changed
those tests to first check if the collation support is available or not and run the tests
only if the support is available. These tests can be modified to not do the check. Instead
let database create fail with the new error message on phoneME and other platforms that do
not support the Collator for locales required by CollationTest and CollationTest2. I can go
ahead and make those changes to the test once I know that the attached patch looks good to
the community.

Please send in your comments, if any, on the attached patch.

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


Mime
View raw message