You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Vemund Østgaard (JIRA)" <ji...@apache.org> on 2008/01/15 16:06:35 UTC
[jira] Created: (DERBY-3320) Database creation and boot should fail
if collation=TERRITORY_BASED and the selected locale is not supported
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
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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581799#action_12581799 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
I have added a test suite in CollationTest to test for a locale that does not have support from JVM. The test suite added is as follows (in CollationTest.suite())
suite.addTest(collatedSuite("xx", "testNorwayCollation"));
The 2nd argument really does not make a difference in this test case because locale "xx" is not supported by the JVM and hence we expect to get an error during database creation. When I run CollationTest, I get expected error for unsupported locale "xx" but I am not able to catch that exception. Apparently, the create database code path is taken through following path
2008-03-25 06:17:34.033 GMT Thread[TestRunner-Thread,6,main] Cleanup action starting
ERROR XBM04: Collator support not available from the JVM for the database's locale 'xx'.
at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
at org.apache.derby.iapi.types.DataValueFactoryImpl.verifyCollatorSupport(DataValueFactoryImpl.java:1160)
at org.apache.derby.iapi.types.DataValueFactoryImpl.boot(DataValueFactoryImpl.java:156)
at org.apache.derby.iapi.types.J2SEDataValueFactory.boot(J2SEDataValueFactory.java:45)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:189)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1836)
at org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentService(BaseMonitor.java:1024)
at org.apache.derby.iapi.services.monitor.Monitor.createPersistentService(Monitor.java:596)
at org.apache.derby.impl.jdbc.EmbedConnection.createDatabase(EmbedConnection.java:2319)
at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:363)
at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:73)
at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(EmbedConnection40.java:54)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68)
at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:238)
at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSource.java:478)
at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSource.java:422)
at org.apache.derbyTesting.junit.Decorator$2.setUp(Decorator.java:185)
at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:59)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:59)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.swingui.TestRunner$16.run(TestRunner.java:623)
I thought I could overwrite the run() method in CollaitonTest as follows and I would be able to trap the unavailable Collator exception and move on to the next test. But the code in catch block never gets executed.
public final void run(junit.framework.TestResult result) {
try {
super.run(result);
} catch (Exception ex) {
if (ex instanceof SQLException){
SQLException sqle = (SQLException)ex;
assertEquals("Unexpected error when connecting to database ",
"XBM04",
sqle.getSQLState());
}
}
}
Anyone has any tips on how I can successfully catch the exception thrown at the database create time and assert that it is XBM04.
> 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.
[jira] Updated: (DERBY-3320) Database creation and boot should fail
if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582028#action_12582028 ]
Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------
Why not just attempt to create the database directly in the text fixture. The decorator for collated database is intended to provide a working database for collation tests, it's not intended as a general test fixture.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579910#action_12579910 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
I spent some time on this jira entry and found that we get the Locale and Collator for the database even before we know that we are dealing with a territory based database. This happens in DataValueFactoryImpl.setLocale which gets called by BasicDatabase.boot(). The reason we do this setting before the store module and data dictionary module boots up is so that Collator info is available to store if needs to do recovery. I am trying to tackle the problem first for database create time only(will address subsequent boot times later on). I will try to see if I can find the request for territory based database during DataValueFactory module bootup so we can see if Collator is really supported or not for the given locale.
> 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_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.
[jira] Updated: (DERBY-3320) Database creation and boot should fail
if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-3320:
----------------------------------
Component/s: Services
> 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
> Components: Services
> Affects Versions: 10.4.1.3
> 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
> Fix For: 10.3.3.0, 10.4.1.3, 10.5.0.0
>
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Vemund Østgaard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585566#action_12585566 ]
Vemund Østgaard commented on DERBY-3320:
----------------------------------------
Now that suites.All is running again on Java ME, I discovered that the new test in CollationTest fails on this platform. I tested on phoneME advanced and saw:
There was 1 failure:
1) testMissingCollatorSupport(org.apache.derbyTesting.functionTests.tests.lang.CollationTest)junit.framework.AssertionFailedError: could not instantiate driver
at org.apache.derbyTesting.functionTests.tests.lang.CollationTest.loadDriver()V(CollationTest.java:1320)
at org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testMissingCollatorSupport()V(CollationTest.java:1250)
at org.apache.derbyTesting.junit.BaseTestCase.runBare()V(BaseTestCase.java:103)
at sun.misc.CVM.runMain()V(CVM.java:514)
AFAIK java.sql.Driver and DriverManager is not supported with JSR169, only DataSource.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581580#action_12581580 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Mike Matrigali had following comment on derby list
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.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586677#action_12586677 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Merged 643292 and 645665 from trunk into 10.3 codeline. The revision for 10.3 merge is 645775.
> 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
> Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0
>
> 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.
[jira] Assigned: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor reassigned DERBY-3320:
--------------------------------------
Assignee: Mamta A. Satoor
> 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
>
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577157#action_12577157 ]
Knut Anders Hatlen commented on DERBY-3320:
-------------------------------------------
Wasn't the problem that if a locale wasn't supported, the Collator would be instantiated anyway and silently use en_US? If that was the problem, I don't think checking that the Collator can be instantiated will help.
> 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_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.
[jira] Resolved: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Dyre Tjeldvoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dyre Tjeldvoll resolved DERBY-3320.
-----------------------------------
Resolution: Fixed
> 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
> Fix For: 10.4.0.0, 10.5.0.0
>
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580423#action_12580423 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
In DVF.setLocale, the Collator object gets created whether we are dealing with territory based database or not. If the database is not territory based, then the Collator object never gets used. But if it is a territory based database, then Store might use the Collator object if it needs to database recovery.
I think we can check if the Collator object can be created or not for the given locale irrespective of whether it is territory based db or UCS_BASIC db. So, I will go ahead and do the check and not worry about whether it is boot/create time and whether we are dealing with territory based db or not.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586523#action_12586523 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Checked in a fix for DriverManager vs DataSource issue with the newly added test. JSR169 does not support DriverManager. I changed the test to use TestUtil.getConnection rather than getting the Connection directly through DriverManager.getConnection. The change went in as 645665 into trunk. I will merge this into 10.4 codeline later.
> 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
> Fix For: 10.4.0.0, 10.5.0.0
>
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580106#action_12580106 ]
Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------
Why not just throw an exception when the collator object is created if the locale is not supported?
Then there's no need to figure out if it's boot or create database time.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581593#action_12581593 ]
Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------
You can always just make up a locale that doesn't exist, xx_zz
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577171#action_12577171 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Sorry for the brief comment "making sure that Collator can be instantiated for the locale on a give JVM ". Let me elaborate on what I am thinking of doing.
Collator class has a method called getAvailableLocales which returns an array of locales which are the union of locales supported by the Java runtime and by installed CollatorProvider(a subclass of LocaleServiceProvider) implementations.
Locale class also has a method called getAvailableLocales which returns an array of locales which are the union of locales supported by the Java runtime and by installed LocaleServiceProvider implementations.
So, it appears that the locale arrary returned from Collator.getAvailableLocales will be a subset of locale array returned by Locale.getAvailableLocales
What I was thinking of doing was adding a new method (don't know in which class at this point) which will go through the arrary returned by Collator.getAvailableLocales and see if the locale requested by the user is included in the locale arrary. If not, then throw an exception. I was planning on calling this method when I find at database create/boot time that user has asked for territory based collation.
After thinking more about it, I think it will be better for us to make the new method more generic by going through Locale.getAvailableLocales rather than the Collator.getAvailableLocales. And then seee if the locale requested by the user is inclueded in the locale array. Making the method generic this way will enable us to use it for other Derby functionality that uses the database locale (some of this functionality has been identified by Dan in his earlier comment to this jira entry).
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566219#action_12566219 ]
Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------
The list of Derby functionality that uses the database locale is (are there any others?)
- error messages : not a requirement that the database locale is supported, error messages will default to English.
- collation - index order is dependent on the ordering, thus the database locale must be supported for collation.
- UPPER/LOWER - in order to have consistent results the database locale must be supported
One possible additional case is the conversion of java date time values to DATE/TIME/TIMESTAMP, that though may use the locale of the jvm.
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577500#action_12577500 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Thanks, Vemund and Knut. I was under the impression that if a locale is avaialble through Locale.getAvailableLocales(), then all the locale related functionality (including Collation) is automatically available. But it appears that it is not correct. Based on this, I will go ahead and code to look for Collator.getAvailableLocales rather than Locale.getAvailableLocales(). Is there a need to look at Locale.getAvailableLocales() also or is Collator.getAvailableLocales() sufficient?
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581597#action_12581597 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
That worked, I tried it with my changes for catching requested locale that does not exist at database create time.Thanks, Dan.
$ java org.apache.derby.tools.ij
ij version 10.5
ij> connect 'jdbc:derby:c:/dellater/dbTerritory;create=true;territory=xx_zz;collation=TERRITORY_BASED';
ERROR XJ041: Failed to create database 'c:/dellater/dbTerritory', see the next exception for details.
ERROR XBM04: Collator support not available from the JVM for the database's locale 'xx_ZZ'.
ij> exit;
> 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.
[jira] Updated: (DERBY-3320) Database creation and boot should fail
if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ 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_Repro.java
I am working on trying to find a way to check for a territory based database, if the Locale requested by the user is supported by the JVM or not.
I thought there would be a straightforward JAVA api which will let me provide the language and country and tell me if the Locale for it is supported by the JVM or not. But I didn't find any such api.
A have attached stand alone test case DERBY_3320_Repro.java which shows how I have to use Locale.getAvailableLocales() and go through it to determine if a specific Locale is supported or not. Am I correct or did I miss some simpler way of achieveing this?
Thanks for looking at this.
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580486#action_12580486 ]
Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------
The general approach looks good, though I would say all the create logic going into setLocale() really should be in
DataValueFactoryImpl.boot()
Then this avoids the need to change the signature of setLocale().
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577221#action_12577221 ]
Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------
Mamta> see if the locale requested by the user is included in the locale arrary
What does that mean, especially with regards to this comment:
Vemund> Something to consider is also whether you need an exact match to consider a locale supported for the purpose of the Collator, or if it is enough to get a language match? For instance, if looking for en_GB, is en_US good enough?
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580436#action_12580436 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Dan wrote "Thinking about it more though, that might be sometime later than create/boot." I am not sure if that is correct, In case of recovery, store will need the collator object during boot.
Based on the same thinking, in future, when a database may have many collations associated with it, we might need to make sure the all collations are supported at db boot time because they may be required during store recovery at the database boot time.
> 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.
[jira] Updated: (DERBY-3320) Database creation and boot should fail
if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor updated DERBY-3320:
-----------------------------------
Fix Version/s: 10.5.0.0
10.4.0.0
> 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
> Fix For: 10.4.0.0, 10.5.0.0
>
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Vemund Østgaard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562434#action_12562434 ]
Vemund Østgaard commented on DERBY-3320:
----------------------------------------
I am not sure if there is an easier way to check for Locale support, I used your method when making a patch for the tests to avoid running them when the locale to test with was not available. It has not been committed yet, though.
I think maybe that Locale.getAvailableLocales() doesn't necessarily have to return the same list of supported Locales as Collator.getSupportedLocales(), or other locale-dependent classes with the getSupportedLocales() method. So maybe it is important to check what returned by the functionality that will be used, like Collator.
Take a look at the javadoc for java.util.spi.LocaleServiceProvider, it seems all the different locale-dependant provider classes are subclasses of this. The second last paragraph says:
Locale sensitive factory methods and methods for name retrieval in the java.text and java.util packages invoke service provider methods when needed to support the requested locale. The methods first check whether the Java runtime environment itself supports the requested locale, and use its support if available. Otherwise, they call the getAvailableLocales() methods of installed providers for the appropriate interface to find one that supports the requested locale. If such a provider is found, its other methods are called to obtain the requested object or name. If neither the Java runtime environment itself nor an installed provider supports the requested locale, a fallback locale is constructed by replacing the first of the variant, country, or language strings of the locale that's not an empty string with an empty string, and the lookup process is restarted. In the case that the variant contains one or more '_'s, the fallback locale is constructed by replacing the variant with a new variant which eliminates the last '_' and the part following it. Even if a fallback occurs, methods that return requested objects or name are invoked with the original locale before the fallback.The Java runtime environment must support the root locale for all locale sensitive services in order to guarantee that this process terminates.
So, I think you will have to go through the list of supported locales for the functionality that will be used. Maybe that is only Collator?
Something to consider is also whether you need an exact match to consider a locale supported for the purpose of the Collator, or if it is enough to get a language match? For instance, if looking for en_GB, is en_US good enough? Maybe if a partial match is found, the DB should be allowed to boot but write a warning about it only finding a partial match?
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585641#action_12585641 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
I have migrated the revision 643292 from trunk into 10.4 codeline with revision 644779. I will work on migrating it to 10.3 codeline as well.
> 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
> Fix For: 10.4.0.0, 10.5.0.0
>
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584028#action_12584028 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Committed changes into trunk with revision 643292. At the top level, following describes the changes that went in as 643292.
DERBY-3320 This commit will ensure that if the Collator support does not exist during a territory based database creation, then we will throw an exception saying Collator support does not exist. In case of subsequent boot of a successfully created territory based database, we will check for the Collator support from JVM at the time first collation related operation is run on the database. This can happen if the database recovery needs to be done at the boot time or it can happen after the database has booted and user has issued a SQL which requires Collator support.
The details of the changes that went into different classes can be seen in the commit comments.
I added a test case for a territory based database creation with a locale for which Collator support does not exist. There is no test case for database recovery and missing Collator support yet. There is also no test for successful territory based database boot but detecting no Collator support when a SQL is issued which requires Collator support.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577235#action_12577235 ]
Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------
Sorry missed earlier comment about exact match on locale.
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577151#action_12577151 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Also, I am considering throwing an exception if the exact locale is not found. If anyone has any comments on this proposed behavior, please add a comment to this jira entry.
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582013#action_12582013 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
It appears that database creation happens through TestSetup heirarchy. CollationTest on the other hand does not extend TestSetup. It extends TestCase and I think that is why my run() method in CollationTest does not really get the exception thrown through the TestSetup class hierarchy. I will keep looking but if anyone has any ideas, please pass them along. Basically, what I am looking for is catching the exception thrown during the database creation time in CollationTest so that I can ignore Collator support not available exception.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Vemund Østgaard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577882#action_12577882 ]
Vemund Østgaard commented on DERBY-3320:
----------------------------------------
I think it is sufficient as a first increment at least to check just Collator.getAvailableLocales().
I think you are correct in your earlier assessment that the locales returned by Collator.getAvailableLocales() is a subset of the locales returned by Locale.getAvailableLocales(), so if you find the locale in the first list it should also be in the second.
> 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_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.
Re: [jira] Updated: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by Mike Matrigali <mi...@sbcglobal.net>.
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.
>
[jira] Updated: (DERBY-3320) Database creation and boot should fail
if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Vemund Østgaard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577486#action_12577486 ]
Vemund Østgaard commented on DERBY-3320:
----------------------------------------
My understanding is along the lines of what Knut writes, that the set of locales supported by Collator and Locale in theory can be different.
If collation=TERRITORY_BASED the selected locale should be one of those returned by Collator.getAvailableLocales().
See also my comment on Jan. 25. 08.
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585205#action_12585205 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
I am researching into how support for a Collator can be removed from a JVM. What I am hoping to accomplish is create a territory based database with say Norwegian locale. Then shutdown the database and remove the support for Norwegian locale from the JVM in such a way that the Collator object for Nrowegian local can not be instantiated for that JVM. Then boot the database again and issue a SQL which requires collation operation and that SQL should fail because Collator could not be found for Norwegian. If anyone has any ideas on removal of Collator, please post a comment here.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580442#action_12580442 ]
Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------
I don't think store needs the collator if there is no recovery to perform (e.g. clean shutdown previously), so that's what I meant by "might be sometime later".
So I'm saying if the database has tables with three collations A,B,C and the current vm only supports A,C, then if recovery does not touch any table with B, then why not let the database boot. If recovery needed B then an exception would be thrown and the database would fail to boot.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586921#action_12586921 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
The only item remaining on this issue is adding 2 test cases. The test cases that will be nice to have are 1)create a territory based database, then crash it, then make sure that the Collator support for the database's locale is not available anymore and then try to reboot the database, This should make the database go through the recovery and the recovery code should fail because Collator support does not exist 2)create a territory based database, then shut it down, then make sure that the Collator support for the database's locale is not available anymore and then reboot the database. The database reboot should succeed because it did not need access to Collator. Now, issue a SQL which will do a collation operation and then collation operation should fail because Collator is not available.
The manual steps in ij for test case 1 would be
connect 'jdbc:derby:c:/dellater/dbTerritory;create=true;territory=no;collation=TERRITORY_BASED';
create table t1(c11 int, c12 char(4));
create index i1 on t1(c12);
autocommit off;
insert into t1 values (1,'11'),(2,'22');
insert into t1 values (3,'33'),(4,'44');
delete from t1 where c11=1;
--IMPORTANT STEP. Ctrl-C out of ij. ie do not exit but instead, force a database crash by doing Ctrl-C
Now, remove the Collator support for Norway and restart ij again and following reboot of the db should fail
connect 'jdbc:derby:c:/dellater/dbTerritory';
The manual steps in ij for test case 2 would be
connect 'jdbc:derby:c:/dellater/dbTerritory;create=true;territory=no;collation=TERRITORY_BASED';
create table t1(c11 int, c12 char(4));
insert into t1 values (1,'11'),(2,'22');
exit;
--IMPORTANT STEP Remove the Collator support for Norway and restart ij and connect to the database
connect 'jdbc:derby:c:/dellater/dbTerritory';
--following SQL will fail because it requires acces to Collator
select * from t1;
I have not spent the time on Vemund's suggestion about creating and adding a custom Collator and removing it. I will go ahead and enter a new jira entry for exploring custom Collator and then using it to add the 2 test cases mentioned above. In the mean time, I did hand tweaked the Derby code to make sure that the above 2 test cases fail in my client as expected.
In both the test cases above, before we restart the ij, I changed DataValueFactoryImpl.verifyCollatorSupport code to always throw an exception that Collator is not found. So, my changes in DataValueFactoryImpl.verifyCollatorSupport would look as follows
Locale[] availLocales = Collator.getAvailableLocales();
//Verify that Collator can be instantiated for the given locale.
boolean localeFound = false;
for (int i=0; i<availLocales.length;i++)
{
if (availLocales[i].equals(databaseLocale)) {
localeFound = true;
break;
}
}
if (1==1) // THIS IS WHAT i CHANGED. RATHER THAN CHECKING FOR LOCALEFOUND, I DO 1==1 SO THE EXCEPTION WILL BE THROWN
//if (!localeFound)
throw StandardException.newException(
SQLState.COLLATOR_NOT_FOUND_FOR_LOCALE,
databaseLocale.toString());
return (RuleBasedCollator) Collator.getInstance(databaseLocale);
But as we can see, this code obviously can't be checked in. I just did it in my local codeline to simulate missing Collator support during database recovery or during subsequent database boot with first SQL with collation support requirement. I will go ahead and enter a jira entry for a more graceful way of removing Collator in order for us to have the 2 test cases in our junit test suite.
> 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
> Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0
>
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580432#action_12580432 ]
Daniel John Debrunner commented on DERBY-3320:
----------------------------------------------
That's not exactly what I meant, I was more thinking of just throwing an error when a collator was requested (ie. needed for collation) and could not be created. Thinking about it more though, that might be sometime later than create/boot.
Though I'm not sure if that's a problem. Thinking about the future, a database may have many collations associated with it. Will it be a requirement that all collations are supported on the current jvm before the database can be booted?
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Vemund Østgaard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585564#action_12585564 ]
Vemund Østgaard commented on DERBY-3320:
----------------------------------------
I'm not sure if there is any easy way to accomplish what you want.
What comes to mind is that I think you could write your own CollatorProvider. This CollatorProvider could be written in a way that allows you to instrument it to behave the way you want. This CollatorProvider would extend the support in the jdk/jre with some dummy Collator for a made up Locale when you want it to. Then, when you want it to no longer provide support for that Locale, you just tell it not to by setting a property or something. Basically you could just tell it to support any Locale, the jre will call a method:
public abstract Collator getInstance(Locale locale)
that you implement yourself in your CollatorProvider.
The javadoc for LocaleServiceProvider says a bit about how to package such an extension. I don't know if this is a feasible path but it might be worth looking into.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586554#action_12586554 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Migrated test changes into 10.4 codeline with revision 645706.
> 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
> Fix For: 10.4.0.0, 10.5.0.0
>
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577186#action_12577186 ]
Knut Anders Hatlen commented on DERBY-3320:
-------------------------------------------
Thanks, that makes sense.
> After thinking more about it, I think it will be better for us to
> make the new method more generic by going through
> Locale.getAvailableLocales rather than the
> Collator.getAvailableLocales.
What if Locale.getAvailableLocales() says that a locale is available
and Collator.getAvailableLocales() says that we don't have collators
for that locale? If we only look at Locale.getAvailableLocales(),
won't we incorrectly conclude that we support collation for that
locale and create an en_US Collator?
> 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_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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585639#action_12585639 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Vemund thanks for your comments. I will further investigate into what you suggested. I will also look into DriverManager vs DataSource issue.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586933#action_12586933 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
I have added jira entry DERBY-3608 for 2 additional test cases that could be added.
> 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
> Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0
>
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581583#action_12581583 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Mike asked, "I assume you have the simple test case for creating the db with just picking a territory that does not exist anywhere. " I do not have a territory which I know will not exist anymore. I will work on writing a standalone Java program to see if it is possible to determine a missing territory on a given JVM with some while loop. In the meantime, if anyone has any ideas on how to find such a territory, please share them.
> 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.
[jira] Updated: (DERBY-3320) Database creation and boot should fail
if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-3320:
----------------------------------
I think it is reasonable in the current system to check at create database time and throw an error then rather than wait until a table with a user char column is created. But for an existing db I do think it is ok to delay the check until the actual use of the
Collator, if we can make the error somewhat obvious to the user what is going on. Do test that the error makes it to the user if we fail in recovery as there have been problems in the past with errors during boot getting eaten and the user just gets a
could not boot message with module startup failure.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577136#action_12577136 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Currently, I am thinking of concentrating only on making sure that Collator can be instantiated for the locale on a give JVM when a user is trying to create/boot a database with territory based collation.
> 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_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.
[jira] Issue Comment Edited: (DERBY-3320) Database creation and
boot should fail if collation=TERRITORY_BASED and the selected locale is
not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582013#action_12582013 ]
mamtas edited comment on DERBY-3320 at 3/25/08 9:57 AM:
-----------------------------------------------------------------
It appears that database creation happens through junit.extensions.TestSetup heirarchy. CollationTest on the other hand does not extend TestSetup. It extends junit.framework.TestCase and I think that is why my run() method in CollationTest does not really get the exception thrown through the TestSetup class hierarchy. I will keep looking but if anyone has any ideas, please pass them along. Basically, what I am looking for is catching the exception thrown during the database creation time in CollationTest so that I can ignore Collator support not available exception.
was (Author: mamtas):
It appears that database creation happens through TestSetup heirarchy. CollationTest on the other hand does not extend TestSetup. It extends TestCase and I think that is why my run() method in CollationTest does not really get the exception thrown through the TestSetup class hierarchy. I will keep looking but if anyone has any ideas, please pass them along. Basically, what I am looking for is catching the exception thrown during the database creation time in CollationTest so that I can ignore Collator support not available exception.
> 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.
[jira] Commented: (DERBY-3320) Database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580445#action_12580445 ]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
So, seems like there could be 2 approaches here.
During the boot, if the access to Collator object is required, then verify at that time that the Collator object can be created for the given locale. Once, the recovery/boot is over, 1)right before leaving the boot process, make sure that the Collator object can be created if it has not already been created. This would mean that if the database has tables with three different collations, then all those Collator objects should be supported by JVM once the boot process is over. 2)wait until the first access to Collator object and verify that Collator object can be instantiated. So, user may not find until much later in the database session(when they actually need to use the Collator object) that the required Collator object is not available.
> 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.
[jira] Updated: (DERBY-3320) Database creation and boot should fail
if collation=TERRITORY_BASED and the selected locale is not supported
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor updated DERBY-3320:
-----------------------------------
Fix Version/s: 10.3.2.2
> 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
> Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0
>
> 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.