[
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
DERBY2524_Collation_Info_In_DTD_v2_diff.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 DERBY2524_Collation_Info_In_DTD_v1_diff.txt.
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: 10.3.0.0
> 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.
