Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <13891977.1173240684151.JavaMail.root@brutus>
Date: Tue, 6 Mar 2007 20:11:24 -0800 (PST)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2336) Enable collation based ordering for
 CHAR data type.
In-Reply-To: <651053.1171485066130.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-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478678 ] 

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

I think I have a good interim solution, move all use of locale related to data types into DataValueFactory.

  - Database (BasicDatabase) continues to own the locale of the database

  - BasicDatabase after booting DataValueFactory calls a new method on DataValueFactory
              void setLocale(Locale)
  - Store uses DataValueFactory to get DataValueDescriptors from a format identifier instead of through the monitor (requires a new method on DataValueFactory like)
              DataValueDescriptor getNullValue(int format_id)

  -  DataValueFactory does whatever it needs with Locale, e.g. has a single RuleBasedCollator object for the locale and passes that into the new SQLChar variants that use a Collator for comparision.

  - LocaleFinder as a class can probably go away, though that could be delayed until the new SQL Char variants exist and the old national character types have been removed. I think its only use is the old style national character collation (and was driven by the hack in gettting the locale from a context) which will not be needed with the new code.

This seems like a logical breakdown of responsibility, data type stuff in the data value factory :-)

While it doesn't handle the future issues of different collations per schema etc. I think it can be expanded to handle it e.g. a new set of format identifiers for collators like case-insensitive. At least the code is self-contained in a logical place.


> Enable collation based ordering for CHAR data type.
> ---------------------------------------------------
>
>                 Key: DERBY-2336
>                 URL: https://issues.apache.org/jira/browse/DERBY-2336
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Mamta A. Satoor
>         Attachments: DERBY_LocalFinder_CodeCleanup_diff_V01.txt, DERBY_LocalFinder_CodeCleanup_stat_V01.txt
>
>
> I am breaking down the Parent task DERBY-1478 (Add built in language based ordering and like processing to Derby) into multiple sub tasks. One of them is to concentrate on enabling the collation based ordering on (hopefully the simplest of all the character data types) CHAR data type. This task in itself might need subtasks if it is later found that it can be subdivided into multiple smaller steps.

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