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] Commented: (DERBY-2599) Set correct collation type and derivation on DataTypeDescriptor(DTD).
Date Thu, 24 May 2007 20:59:16 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498831

Mamta A. Satoor commented on DERBY-2599:

Made a commit earlier today - revision 541381

ResultColumn's convertConstant method has 2 calls to DataValueFactory.getVarcharDataValue(String)
which will always create SQLVarchar and disregard any collation information that it should
be using. This gets called for an INSERT statement while trying to do column type and length
matching from the source resultset into the target. The change through this commit makes sure
we set the correct collation type and derivation. Some background information on this change
from a thread titled "Possible missing collation info for DVDs?" on Derby dev mailing list

Snippet start from the thread mentioned above.
I looked at ResultColumn's convertConstant method which has the 2 calls to DataValueFactory.getVarcharDataValue(String).
This method gets called in following sequence
convertConstant(TypeId, int, DataValueDescriptor) - org.apache.derby.impl.sql.compile.ResultColumn
 columnTypeAndLengthMatch(ResultColumn) - org.apache.derby.impl.sql.compile.ResultColumn
 columnTypesAndLengthsMatch(ResultColumnList) - org.apache.derby.impl.sql.compile.ResultColumnList
  bindStatement() - org.apache.derby.impl.sql.compile.InsertNode

It looks like InsertNode's bindStatement method calls columnTypesAndLengthsMatch to make sure
that the source and target column types and lengths match and if not, then it should insert
a NormalizeResultSetNode  on top of the source. If the source happens to have constants, then
we try to convert the constant to the type of the target(this happens in ResultColumn's convertConstant

Since none of this code flow happens for a collation operation, in theory, it will be ok with
not setting the correct collation type and derivation and hence the code should not run into
any problem even if it stayed as it is. If my understanding is wrong about how the constants
in the insert statement can't be part of a collation operation, then please let me know. Ideally
though, it will not hurt to have the correct collation type and derivation setting on constants
in this case whether or not they get used in a collation method. So,
I will go ahead and do that. 
Snippet end from the thread mentioned above.

> Set correct collation type and derivation on DataTypeDescriptor(DTD).
> ---------------------------------------------------------------------
>                 Key: DERBY-2599
>                 URL: https://issues.apache.org/jira/browse/DERBY-2599
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions:
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>         Attachments: DERBY2599_collationType_default_UCS_BASIC_v1_diff.txt, DERBY2599_collationType_default_UCS_BASIC_v1_stat.txt,
DERBY2599_correct_collation_for_cast_v1_diff.txt, DERBY2599_correct_collation_for_cast_v1_stat.txt,
DERBY2599_getNull_should_set_collation_info_v1_diff.txt, DERBY2599_getNull_should_set_collation_info_v1_stat.txt,
DERBY2599_IntermediatePatch_v1_diff.txt, DERBY2599_IntermediatePatch_v1_stat.txt, DERBY2599_Set_collation_for_aggregates_v1_diff.txt,
DERBY2599_Set_collation_for_aggregates_v1_stat.txt, DERBY2599_Set_collation_for_aggregates_v1_stat.txt,
> DTD has TypeDescriptorImpl in it which has 2 new fields, namely, collationType and collationDerivation.
These 2 fields are available for all different types of DTDs but only apply to character types.
The other datatypes should ignore these 2 fields.
> This Jira is a placeholder for loading the correct values into collationType and collationDerivation.

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

View raw message