[
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_not_ready_for_commit_stat_v1.txt
DERBY_3320_not_ready_for_commit_diff_v1.txt
Patch DERBY_3320_not_ready_for_commit_diff_v1.txt not ready for commit.
I have added code in DataValueFactoryImpl.setLocale to see if we are dealing
with database create time and if user has asked for territory based database in
JDBC url. If yes, then verify that a Collator object can be instantiated for
the requested locale. If not, then throw an exception.
Notice though that this does not take care of subsequent database boot up time.
A user might boot up a territory based database on a machine that does not have
Collator support for the locale. The reason I could not do the check for
Collator during subsequent boot up time is that at this time of Derby bootup
(ie when we are in DVF.setLocale method), we do not have access to the
information if the database is territory based or not. That information becomes
available after the store has finished booting up. But store bootup happens
after DVF bootup finishes.
We can not wait for store to finish booting up to decide if the Collator
support is available because store during bootup may need to go through the
recovery and at the time of recovery, we need access to Collator object. So,
this is a kind of catch 22 during subsequent database bootup time. We need to
know if the databsase is territory based to see if we need to check Collator
support. But to know if the database is territory based, we need for store to
finish booting up. But store during bootup may require access to Collator if it
needs to recover the db.
A solution could be to always check if the Collator support is available for
the locale of the database, whether or not user has requested territory based
database. This can be done in DVF.setLocale. This approach will be fine IF we
know that there will always be Collator support for the default locale of the
JVM when dealing with the non-territory based databases.
Please ask questions if this store recovery and Collator dependency is not
clear.
> 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.
