Made a checkin (revision 541381) for 2 calls to DataValueFactory.getVarcharDataValue(String) in ResultColumn's convertConstant method. The checkin went as part of DERBY-2599
Part of the commit comments are as follows 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. Mamta On 5/23/07, Mamta Satoor <[EMAIL PROTECTED]> wrote:
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. That will help me write a good test case for this insert case. 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. thanks, Mamta On 5/22/07, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > > These two classes have direct calls to DataValueFactory methods that > return a CHAR/VARCHAR DataValueDescriptor with UCS_BASIC collation. > > CharConstantNode > Two calls to DataValueFactory.getCharDataValue(String) > > ResultColumn > Two calls to DataValueFactory.getVarcharDataValue(String) > > > I wonder if they should instead be obtaining a CHAR/VARCHAR value based > upon collation settings? > > Dan. > > > > > > >
