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