[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580477#action_12580477
]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
I am starting to think of the implementation for the following approach
At the db create time, we will give the error for Collator not available (if
that is the case) when the database is getting created rather than wait until a
user creates a table with char column. For the database boot time, throw the
error whenever the Collator is accessed first(ie not right towards the end of
the boot time in BasicDatabase). This first access can happen because recovery
was required during boot time or later when user has triggered access to
Collator through SQL.
With the above approach in mind, I am thinking that I will keep the changes in
DVF.setLocale(the changes shown in the patch attached to this jira entry) where
I check if we are in here for database create time and check for Collator
object and if found, put it in collatorForCharacterTypes class variable. If not
for database create time, don't even create the Collator object in
DVF.setLocale ie do not load collatorForCharacterTypes.
DVF has a method called getCharacterCollator which now will have to see if it
is dealing with territory based db, If yes, then check if
collatorForCharacterTypes is not null. If not null, then return
collatorForCharacterTypes otherwise it mean that Collator object is getting
accessed for the first time and hence check if the JVM supports it. If not,
then throw exception. If it is supported, then put the Collator object in
collatorForCharacterTypes and return collatorForCharacterTypes from
getCharacterCollator. So, as we can see, now we will have an additional check
for territory based db in getCharacterCollator to see if
collatorForCharacterTypes is null or not and if null, then verify that Collator
is supported by the JVM. Pseudo code follows
DVF.getCharacterCollator (as it is in trunk)
if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
return (RuleBasedCollator)null;
else
return collatorForCharacterTypes;
The new code for DVF.getCharacterCollator will be
if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
return (RuleBasedCollator)null;
else if (collatorForCharacterTypes == null) {
Collator object supported by JVM for
databaseLocale?
If not, throw exception
If yes, then
collatorForCharacterTypes = Collator object
return collatorForCharacterTypes;
} else
return collatorForCharacterTypes;
> 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_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.
