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 and SQLVarch which will use the passed Collator to do the collation rather than the default collation of UCS_BASIC
Date Fri, 30 Mar 2007 07:11:25 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_CollationSensitiveVarcharShell_stat_v1.txt

I would like to submit a patch (DERBY2416_CollationSensitiveVarcharShell_diff_v1.txt), which
provides a subclass of SQLVarchar called CollatorSQLVarchar. This new class differs from it's
superclass in how a non-default Collator is used for collation sensitive methods.

The main problem that I came across while working on this patch is that Java does not allow
multiple inheritence. Currently, the iapi.types package has SQLChar as the base class. From
this SQLChar, we have 2 subclasses, namely, CollatorSQLChar and SQLVarchar. At the moment,
CollatorSQLChar overrides the collation sensitive methods(currently, there is only one collation
sensitive method in CollatorSQLChar called like. More will be added later) from SQLChar. In
order to provide a non-default collation implementation of SQLVarchar, I need to subclass
SQLVarchar, but I can't simultaneously inherit from CollatorSQLChar method to get the collation
sensitive implementation of the like method. Becuase of this limitation, one option is to
duplicate the implementation ofcollation sensitive methods from CollatorSQLChar into CollatorSQLVarchar.
That also means that we will have to duplicate the code in Collation sensitive subclasses
of SQLLongvarchar and SQLClob. That is code duplicaiton in 4 classes.

In order to avoid this code duplication, I am introducing a new helper class called WorkHorseForCollatorDatatype.
This new class will keep the Collator and the SQLChar object whose data needs to be collated.
The new class's like method will user the Collator object on SQLChar to do the comparison.
Now, the non-default collation implementation of SQLChar and SQLVarchar can simply instantiate
the new WorkHorseForCollatorDatatype class and delegate all the work for like method to WorkHorseForCollatorDatatype.
This will avoid the code duplication and will keep the code in one central place.

In addition, I have added a new interface called CollationElementsInterface. This interface
should be mplemented by all the non-default collation implementation subclasses. The methods
defined in the interface will be used by the like method(and other collation methods in future)
in WorkHorseForCollatorDatatype. 

These new non-default collation implementations for SQLChar and SQLVarchar are not hooked
into Derby at query compile phase and hence they do not currently get used. More code to follow
later to make these classes active in Derby.

One other change in this package is to remove the formatid for CollatorSQLChar. These formatid
changes for CollatorSQLChar went into revision 516864. But since then, we have changed the
design and rather than adding new datatypes for non-default collation implementations, we
will simply associate a RuleBasedCollator with them and this collator will get used during
collation at runtime. Because of this design change, I am removing the changes related to
new formatid that went in revision 516864. This impacts RegisteredFormatIds.java, StoredFormatIds.java
and CollatorSQLChar.java

svn stat -q 
M      java\engine\org\apache\derby\iapi\services\io\RegisteredFormatIds.java
M      java\engine\org\apache\derby\iapi\services\io\StoredFormatIds.java
A      java\engine\org\apache\derby\iapi\types\CollationElementsInterface.java
M      java\engine\org\apache\derby\iapi\types\DTSClassInfo.java
M      java\engine\org\apache\derby\iapi\types\CollatorSQLChar.java
A      java\engine\org\apache\derby\iapi\types\CollatorSQLVarchar.java
A      java\engine\org\apache\derby\iapi\types\WorkHorseForCollatorDatatypes.java

Please provide your input on this patch. If there are no comments by Monday, April 2nd PST
evening, I will go ahead and checkin this patch. I have fired the tests on my XP machine using
Sun's jdk142 few minutes back but do not expect anything to fail because the new classes introduced
by this patch are not hooked into Derby runtime yet.

> Provide a shell for a subclass of SQLChar and SQLVarch which will use the passed Collator
to do the collation rather than the 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_CollationSensitiveVarcharShell_diff_v1.txt, DERBY2416_CollationSensitiveVarcharShell_stat_v1.txt,
DERBY2416_NewCharClassWithDifferentCollationSupport_diff_v1.txt, DERBY2416_NewCharClassWithDifferentCollationSupport_diff_v2.txt,
DERBY2416_NewCharClassWithDifferentCollationSupport_diff_v3.txt, DERBY2416_NewCharClassWithDifferentCollationSupport_stat_v1.txt,
DERBY2416_NewCharClassWithDifferentCollationSupport_stat_v2.txt, DERBY2416_NewCharClassWithDifferentCollationSupport_stat_v3.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