Jeff, I just read your emails about adding a new method getsTypeFromContext() to avoid jumping hoola hoops with ParameterNode. It certainly sounds much cleaner than having to implement ParameterNode specific methods in ValueNode. I would be interested in knowing what Dan thinks of it too?

On 10/5/05, Mamta Satoor <> wrote:
Other than the ParameterNode casting for setDescriptor method, I found 3 additional places where an object gets casted to ParameterNode to get to methods getJSQLType, getParameterNumber and getDefaultValue. These happen in SQLToJavaValueNode, StaticMethodCallNod and BinaryRelationOperator. Just to see how the tests will run, I have removed the Parameter casting in these 3 instances and have added the 3 methods to ValueNode with the following implementations
 public JSQLType getJSQLType()
  if (dataTypeServices != null)
   return(new JSQLType( dataTypeServices ));
   return null;
 public int getParameterNumber()
  return -1;
 DataValueDescriptor getDefaultValue()
  return null;
My intention behind this is to see how the existing tests and my unary arithmetic test would run without making UnaryOperatorNode a superclass of ParameterNode. I have added methods isParameterNode & setDescriptor to UnaryOperatorNode and I don't do parameter binding for -?/+? until the type of the underneath parameter gets set. (I haven't yet looked at consolidating the 2 type setter methods, but I feel uneasy about putting the 3 ParameterNode specific methods into ValueNode.) Any thoughts?

On 10/5/05, Mamta Satoor <> wrote:
Hi Dan,
I will take you up on your offer to "I'm willing to help out on any issues you discover on this new path." :)
While trying out the implementation you suggested (still not completely done), I noticed that when I try to sue +?/-? in function calls, the code flow is as follows
 at org.apache.derby.impl.sql.compile.SQLToJavaValueNode.getJSQLType(
 at org.apache.derby.impl.sql.compile.MethodCallNode.bindParameters(
 at org.apache.derby.impl.sql.compile.StaticMethodCallNode.bindExpression (
 at org.apache.derby.impl.sql.compile.JavaToSQLValueNode.bindExpression(
 at org.apache.derby.impl.sql.compile.BinaryOperatorNode.bindExpression( :309)
 at org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindExpression(
 at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(
 at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(
 at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(
 at org.apache.derby.impl.sql.compile.ReadCursorNode.bind (
 at org.apache.derby.impl.sql.compile.CursorNode.bind(
 at org.apache.derby.impl.sql.GenericStatement.prepMinion(
 at org.apache.derby.impl.sql.GenericStatement.prepare (
 at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(
 at org.apache.derby.impl.jdbc.EmbedPreparedStatement .<init>(
 at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(
 at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(
 at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(
 at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(
 at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement (
 at org.apache.derbyTesting.functionTests.tests.lang.unaryArithmeticDynamicParameter.main(
SQLToJavaValueNode.getJSQLType after checking isParameterNode does ParameterNode casting so it can get to getJSQLType method. But since UnaryOperatorNode is not of the type ParameterNode, the casting fails, as expected. I can remove the casting but that would mean to implement getJSQLType method in ValueNode as well. But does this method make a sense for ValueNode? If we do decide to add this method, UnaryOperatorNode will simply call the same method on it's operand.

On 10/5/05, Daniel John Debrunner < > wrote:
Daniel John Debrunner wrote:

> On this it seems that there is some current confusion in the code,
> ValueNode has two methods to set the type, setType and setDescriptor.
> So why does ParameterNode need a special set type method setDescriptor,
> and the associated required casting?

I got confused here, ParameterNode.setDescriptor is overriding
ValueNode.setDescriptor, so I'm not sure why the casting to
ParameterNode is required.

Still a move to a single method would be a good thing.