[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580497#action_12580497
]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
I might not be understanding the boot handshake correctly but the signature of
the boot method in DVF is as follows
public void boot(boolean create, Properties properties) throws
StandardException
BasicDatabase.boot has gotten the Locale required for the db through the
following code
if (create)
{
if (startParams.getProperty(Property.CREATE_WITH_NO_LOG) ==
null)
startParams.put(Property.CREATE_WITH_NO_LOG, "true");
String localeID =
startParams.getProperty(org.apache.derby.iapi.reference.Attribute.TERRITORY);
if (localeID == null) {
localeID = Locale.getDefault().toString();
}
databaseLocale = monitor.setLocale(startParams, localeID);
} else {
databaseLocale = monitor.getLocale(this);
}
And then BasicDatabase.boot boots DVF and calls DVF.setLocale so that it can
pass the locale object that it has determined to DVF. It looks like there is no
way to pass that locale info through the boot machinery that we already have in
place. So, if we want DVF.boot to do the Collator checking, it will have to get
its hand on locale in it's boot method by going through code similar to
BasicDatabase.boot (copied above). This seems fine to me because then
everything related to boot is in boot method of the DVF and it does not have to
wait for DVF.setLocale to get it's locale set correctly. If we do decide to go
this path, then we can remove DVF.setLocal from BasicDatabase.boot and do the
locale setting in the DVF boot method.
> 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.
