You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Daniel John Debrunner <dj...@apache.org> on 2007/05/22 20:49:02 UTC
Possible missing collation info for DVDs?
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.
Re: Possible missing collation info for DVDs?
Posted by Mamta Satoor <ms...@gmail.com>.
I looked at CharConstantNode. The correct collation setting happens at bind
time for this node and at the same time, we use that collation to see if we
need to switch from SQLxxx to CollatorSQLxxx. This code is in
CharConstantNode.bindExpression(). I guess this could be done at init time
where you see the 2 calls to DataValueFactory.getCharDataValue(String), but
I think it doesn't matter whether the correct witch from SQLxxx to
CollatorSQLxxx happens at init time or bind time.
As for the ResultColumn, I need to spend little more time on it.
thanks,
Mamta
On 5/22/07, Daniel John Debrunner <dj...@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.
>
>
>
>
>
>
>
Re: Possible missing collation info for DVDs?
Posted by Mamta Satoor <ms...@gmail.com>.
I will look into this 2 classes.
Mamta
On 5/22/07, Daniel John Debrunner <dj...@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.
>
>
>
>
>
>
>
Re: Possible missing collation info for DVDs?
Posted by Mamta Satoor <ms...@gmail.com>.
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 <ms...@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 <dj...@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.
> >
> >
> >
> >
> >
> >
> >
>
Re: Possible missing collation info for DVDs?
Posted by Mamta Satoor <ms...@gmail.com>.
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 <dj...@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.
>
>
>
>
>
>
>