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