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-2524) DataTypeDescriptor(DTD) needs to have collation type and collation derivation. These new fields will apply only for character string types. Other types should ignore them.
Date Thu, 05 Apr 2007 06:45:32 GMT

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

Mamta A. Satoor updated DERBY-2524:

    Attachment: DERBY2524_Collation_Info_In_DTD_v2_stat.txt

I committed a patch (DERBY2524_Collation_Info_In_DTD_v2_diff.txt, svn revision 525729) as
a followup to the earlier commited patch (DERBY2524_Collation_Info_In_DTD_v1_diff.txt svn
revision 525568) . Both these patches are attached to this Jira entry.

svn stat -q
M      java\engine\org\apache\derby\iapi\types\DataTypeDescriptor.java
M      java\engine\org\apache\derby\iapi\types\StringDataValue.java
M      java\engine\org\apache\derby\catalog\TypeDescriptor.java
M      java\engine\org\apache\derby\catalog\types\TypeDescriptorImpl.java

The patch does following to address feedback received on the earlier patch in thread http://www.nabble.com/-jira--Created%3A-%28DERBY-2524%29-DataTypeDescriptor%28DTD%29-needs-to-have-collation-type-and-collation-derivation.-These-new-fields-will-apply-only-for-character-string-types.-Other-types-should-ignore-them.-p9842379.html

1)Moved the constant definitions from TypeDescriptor to StringDataValue.
2)Added javadoc comments for all the constants. One big javadoc comment for one of the constants
in the related constants and other constants in that group will just have a javadoc of @see.

3)I had used string costants for collation derivation since they are more verbose. But that
is more expensive than simply using int. As a middle ground, I have defined collation derivation
constants as int but the names of the constants are verbose :) I also changed the api for
collation derivation to work with int rather than String. Finally, changed collationDerivation
from String to int in TypeDescriptorImpl.
4)Rather than using "error" to indicate incorrect collation derivation, we will just initialize
collation derivation to "none". For all character string types, the collation derivation should
get changed to "implicit" unless we are working with aggregate result type of character string
type and the operands to the aggregate have different collation types.
5)Currently, I only save collation type of a persistent character string type column into
SYSCOLUMNS's COLUMNDATATYPE column. Collation derivation for such character string type is
assumed as "implicit" because that is the only possible option in Derby 10.3 for persistent
columns. But in some future release of Derby, when we will start supporting SQL COLLATE clause,
we will want to differentiate between "explicit" and "implicit" collation derivation for such
persistent columns. So, may be it will be good for us to start saving collation derivation
too. For now, I have added this task as a line item under wiki page http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478
under "Performance/Desirable items" section.
6)I caused several javadoc errors for using @see Classname.methodname rather than @see Classname#methodname.
Sorry about that. Fixed those errors in this patch.

I think with this patch, I have taken care of all the feedback received on the earlier patch

Again, if anyone has any comment on this patch or earlier patch, please let me know.

> DataTypeDescriptor(DTD) needs to have collation type and collation derivation. These
new fields will apply only for character string types. Other types should ignore them.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-2524
>                 URL: https://issues.apache.org/jira/browse/DERBY-2524
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions:
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>         Attachments: DERBY2524_Collation_Info_In_DTD_v1_diff.txt, DERBY2524_Collation_Info_In_DTD_v1_stat.txt,
DERBY2524_Collation_Info_In_DTD_v2_diff.txt, DERBY2524_Collation_Info_In_DTD_v2_stat.txt
> This the one of the ground works for getting different kinds of collations working for
character string types. More information on this project can be found at http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478.
Basically, all the types in Derby have a DTD associated with them. For character string types,
these DTDs should have valid values for collation derivation and collation type. For other
data types, these 2 fields do not apply and should be ignored.
> SQL spec talks about character string types having collation type and collation derivation
associated with them (SQL spec Section 4.2.2 Comparison of character strings). If collation
derivation says explicit or implicit, then it means that there is a valid collation type associated
with the charcter string type. If the collation derivation is none, then it means that collation
type can't be established for the character string type. 
> 1)Collation derivation will be explicit if COLLATE clause has been used for character
string type (this is not a possibility for Derby 10.3, because we are not planning to support
SQL COLLATE clause in this release). 
> 2)Collation derivation will be implicit if the collation can be determined w/o the COLLATE
clause eg CREATE TABLE t1(c11 char(4)) then c11 will have collation of USER character set.
Another eg, TRIM(c11) then the result character string of TRIM operation will have collation
of the operand, c11. 
> 3)Collation derivation will be none if the aggregate methods are dealing with character
strings with different collations (Section 9.3 Data types of results of aggregations Syntax
Rule 3aii). 

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

View raw message