db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1478) Add built in language based ordering and like processing to Derby
Date Mon, 05 Feb 2007 18:32:05 GMT

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

Rick Hillegas commented on DERBY-1478:
--------------------------------------

Hi Mamta,

Thanks for taking on this task. This will be a very useful addition to Derby. I don't see
a functional spec attached to this issue. Can you tell me where I can find the spec?

I'm confused about the distinction between the behavior of user-defined CHAR/VARCHAR and the
behavior of CHAR/VARCHAR columns in system tables. I see that Dan raised this issue on January
16. As I read the code, it appears to me that sql identifiers are forced to upper case according
to the rules of Locale.ENGLISH. I think this happens in SQLUtil.SQLToUpperCase(). I don't
see anything in the SQL spec or in JDBC which gives a special place to that locale. The SQL
spec is a bit hard to read, but I get the impression that identifiers are supposed to follow
the same comparison rules (at least as far as equality is concerned) as other strings. That
is least is how I follow the thread of citations starting in part 2 section 5.4 Syntax Rule
3. The JDBC metadata javadoc talks about sort order but, as far as I can see, does not specify
what locale to use. I find it hard to believe that Locale.ENGLISH has been given a special
place or that the metadata is supposed to sort in a different order from CHAR/VARCHAR. My
personal feeling is that there will be a lot of special cases in the code if we have to use
a different sort order for CHAR/VARCHAR depending on whether the strings come out of user
or system tables. If we are going to make the two kinds of strings behave differently, I would
like to understand more specifics on what problems are being solved and why we think this
is the intention of our standards. Thanks.

> 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
>
> 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.


Mime
View raw message