db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [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:57:49 GMT
Do you have some way of creating a database, but then making the 
Collator not available when you next try to boot the database.  I am 
trying to think of the recovery test case, but need to be able to create
the db using a territory based sorting and then the next test case needs
to boot the db and find that collator not available.

I assume you have the simple test case for creating the db with just 
picking a territory that does not exist anywhere.

Mamta A. Satoor (JIRA) wrote:
>      [ 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.
> 


Mime
View raw message