Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 5470 invoked from network); 15 Jan 2008 15:08:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Jan 2008 15:08:07 -0000 Received: (qmail 88860 invoked by uid 500); 15 Jan 2008 15:07:57 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 88645 invoked by uid 500); 15 Jan 2008 15:07:57 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 88636 invoked by uid 99); 15 Jan 2008 15:07:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jan 2008 07:07:57 -0800 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.18.6.21] (HELO gmp-eb-mail-1.sun.com) (192.18.6.21) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jan 2008 15:07:30 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0FF7WaF027089 for ; Tue, 15 Jan 2008 15:07:34 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUO00701XMF9H00@fe-emea-09.sun.com> (original mail from Vemund.Ostgaard@Sun.COM) for derby-dev@db.apache.org; Tue, 15 Jan 2008 15:07:32 +0000 (GMT) Received: from [129.159.112.187] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUO00C7TY0H8TA0@fe-emea-09.sun.com> for derby-dev@db.apache.org; Tue, 15 Jan 2008 15:07:31 +0000 (GMT) Date: Tue, 15 Jan 2008 16:07:29 +0100 From: Vemund Ostgaard Subject: Re: Setting collation=TERRITORY_BASED when territory is set to an unsupported locale In-reply-to: Sender: Vemund.Ostgaard@Sun.COM To: derby-dev@db.apache.org Message-id: <478CCC31.8000000@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <478B5FC1.5000600@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071119) X-Virus-Checked: Checked by ClamAV on apache.org Thank you for sharing your opinions, Knut and Mamta. I''ve reported this in Jira as DERBY-3320. Vemund Mamta Satoor wrote: > I think that we should fail at both database creation time and boot > time if the requested locale can not be found when collation is > territory based. > > Mamta > > On 1/14/08, Knut Anders Hatlen wrote: > >> Vemund Ostgaard writes: >> >> >>> So, should database creation/boot fail if the collation is territory >>> based and the locale is not supported? >>> >> That sounds reasonable to me. If the Java runtime silently uses en_US >> collators when the database's territory is something different, I think >> we can see a variety of problems if the database is moved between >> systems that support collators for the database's territory and systems >> that don't. For instance, the index entries may appear to be unordered >> and queries that use indices may give strange results. >> >> I think at least database boot should fail when collation is territory >> based and locale isn't supported. For database creation we could >> alternatively detect that the situation has occurred, change the >> collation to UCS_BASIC before the database is created, and add a warning >> explaining what has happened. But I think failing is the best option for >> creation too. >> >> -- >> Knut Anders >> >>