Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <12644392.1170790146048.JavaMail.jira@brutus>
Date: Tue, 6 Feb 2007 11:29:06 -0800 (PST)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1478) Add built in language based ordering
 and like processing to Derby
In-Reply-To: <11092987.1152139470894.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470702 ] 

Daniel John Debrunner commented on DERBY-1478:
----------------------------------------------

Mamta> Dan, you mentioned in one of your comments to this Jira entry that "Currently the uppercasing of SQL statements and identifiers is fixed as English to avoid unexpected issue with other languages". Can you please explaing what you mean by unexpected issues? Is that the same reason for recommending same behavior for system tables?

For the reasons you discovered in StringUtil and quoted above. The Turkish locale changes how a lower case i is upper-cased. Allowing the locale of the database engine to influence the casing of the identifiers can lead to the application having to have different versions of its SQL depending on the locale of the database or more likely, if the application developer is not aware of this issue, unexpected failures 

create table customer( id int)

SELECT ID FROM CUSTOMER - will fail if upper casing of identifiers is Turkish.

Yes, one could try to be consistent in the application, but the schema and application may be developed by different groups. The app developer may only learn of the schema through JDBC metadata thus only knowing that the column is called 'ID'.

> Add built in language based ordering and like processing to Derby
> -----------------------------------------------------------------
>
>                 Key: DERBY-1478
>                 URL: https://issues.apache.org/jira/browse/DERBY-1478
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.1.2.1
>            Reporter: Kathey Marsden
>         Assigned To: Mamta A. Satoor
>         Attachments: DERBY-1478_FunctionalSpecV1.html
>
>
> It would be good for Derby to have built in Language based ordering based on locale specific Collator.
> Language based ordering is an important feature for international deployment.  DERBY-533 offers one implementation option for this but according to the discussion in that issue National Character Types carry a fair amount of baggage with them especially in the form of concerns about conversion   to and from datetime and number types. Rick  mentioned SQL language for collations as an option for language based ordering. There may be other options too, but I thought it worthwhile to add an issue for the high level functional concern, so the best choice can be made for implementation without assuming that National Character Types is the only solution.
> For possible 10.1 workaround and examples see:
> http://wiki.apache.org/db-derby/LanguageBasedOrdering

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.