db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: Possible missing collation info for DVDs?
Date Thu, 24 May 2007 21:33:30 GMT
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 <msatoor@gmail.com> 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 <djd@apache.org> 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.
> >
> >
> >
> >
> >
> >
> >
>

Mime
View raw message