Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <27334844.1173484089655.JavaMail.jira@brutus>
Date: Fri, 9 Mar 2007 15:48:09 -0800 (PST)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2416) Provide a shell for a subclass of
 SQLChar which will use the passed Collator to do the collation rather than
 SQLChar's default collation of UCS_BASIC
In-Reply-To: <19889700.1173296244265.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

I agree with Manish on a shorter name, but I think it should use Collator, not Collation.
The existing SQLChar does have a collation, just not using Collator. Maybe CollatorSQLChar?

The comments for the class indicates it uses a Collator, but the code requires a RuleBasedCollator,
is there some dependency on the collator being a RulesBasedCollator?

The field intLength says it's the size of the array above, but I don't think it is.
It represents the number of valid elements in the intArray array. Also possibly
there could be better names for the array and length, ones that describe what they
are, rather than what datatype they are.

It would be good to have javadoc for all the fields and methods of this class from its inception.

The existing collation code using Collators that you based this class upon could use some
performance improvements. Not sure what to do here, could be a separate clean-up or could be designed
into the class from the start. For example, the full collation array is filled before any comparision
and as coded this requires creating a string. So for LIKE if the pattern is 'A%' and the CHAR
read from disk is 'BXXXXXXXXXXXXXXXXXXXXXXX' the char[] array is converted to a String and then
fully converted into an int[] of collation values, and then compared. Instead creating the
collation on-demand and from the char[] means that only one collation integer value would have
to be created before discarding the value.

> Provide a shell for a subclass of SQLChar which will use the passed Collator to do the collation rather than SQLChar's default collation of UCS_BASIC
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2416
>                 URL: https://issues.apache.org/jira/browse/DERBY-2416
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>         Attachments: DERBY2416_NewCharClassWithDifferentCollationSupport_diff_v1.txt, DERBY2416_NewCharClassWithDifferentCollationSupport_stat_v1.txt
>
>
> This jira entry is one of the tasks involved in implementing DERBY-2336.
> The existing SQLChar datatype has the Derby's default collation which is UCS_BASIC defined on them. With Derby 10.3, we want to support an additional collation for char datatypes which will be based on the territory. This jira issue is the placeholder for creating subclass of SQLChar which will use the passed Collator to do the collation. The current use of this class in Derby 10.3 will be for territory based collation but this class can be used in future for other kinds of collations like case-insensitive etc.

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