[
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
(http://www.nabble.com/Possible-missing-collation-info-for-DVDs--tf3798563.html#a10745343)
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 method).
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: 10.3.0.0
> 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,
> DERBY2599_Set_collation_for_Max_Min_v1_diff.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.
