db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Updated: (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
Date Fri, 09 Mar 2007 19:54:09 GMT

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

Mamta A. Satoor updated DERBY-2416:

    Attachment: DERBY2416_NewCharClassWithDifferentCollationSupport_stat_v1.txt

I have a simple patch (DERBY2416_NewCharClassWithDifferentCollationSupport_diff_v1.txt) which
contains a class for character datatype with it's own collator. The class extends the existing
SQLChar and it is called SQLCharWithNonDefaultCollation (I am always on verbose side while
naming classes and methods. So, if someone has any other suggestion for the new class name,
please feel free to suggest). The class lies in the same package as other datatypes at org.apache.derby.iapi.types.
In addition, I added a new format id for this class in supporting classes RegisteredFormatIds,
StoredFormatIds and DTSClassInfo

For now, I have added bare minimum to this new datatype class just to get started. As the
next incremental step, I am planning to tweak the compile code to generate this datatype somehow.
I will add more collation related methods to the new class as subsequent patches. At this
point, this new class does not get used by Derby. It will get used in subsequent patches.

Also, everything in the new class is not coded from scratch meaning I have copied methods
ike "getIntArray", "like" etc have come from the existing SQLChar class. I made some modifications
to those methods (for some reason, existing SQLChar has collation related code into it which
in my opinion should have been disabled SQLNationalChar. But may be there is a good reason
for it which I am not aware of).

I would like reviewers to take note of following comment at line 125 in the new class
			/* Believe it or not, a String might have more
			 * collation elements than characters.
			 * So, we handle that case by increasing the int array
			 * by 5 and copying array elements.
Basically, when the characters in the string are converted to collation elements, one character
can get translated into say 2 collation elements (more info can be found on it in this url
My question is is there another way of handling array broadening more effectively in the code
rather than allocating a new array with 5 more int spaces and copying the old arrary into
the expanded new array?

Any other comments will be appreciated too.

svn stat -q output is attached as DERBY2416_NewCharClassWithDifferentCollationSupport_stat_v1.txt

> 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:
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>         Attachments: DERBY2416_NewCharClassWithDifferentCollationSupport_diff_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.

View raw message