[
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
DERBY2416_NewCharClassWithDifferentCollationSupport_diff_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
http://www.developertutorials.com/tutorials/java/text-searching-java-050524/page3.html)
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: 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.
