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: [PATCH]Derby-582 Dynamic parameter should be allowed to be the operand of unary operator "-".
Date Wed, 12 Oct 2005 06:22:56 GMT
Hi,
 I have a new patch to allow dynamic parameters for unary minus and unary
plus operator. This is based on the feedback from Jeff and Dan. The unary
minus/plus parameters will determine their types depending on the context.
For this, I have added requiresTypeFromContext to ValueNode which always
returns false. ParameterNode always returns true for this method.
UnaryOperatorNode's requiresTypeFromContext calls the operand's
requiresTypeFromContext if operand is not null.
SimpleStringOperatorNode(subclass of UnaryOperatorNode) ends up overriding
this method and returns false because functions lower and upper are always
typed to String and do not need to get their type from the context.
 I have added 2 methods to UnaryOperatorNode.java, namely
getParameterOperand() and isUnaryMinusOrPlusWithParameter(). There are few
places in engine, where we need to access the underlying parameter and that
is when getParameterOperand() gets used. This is required to directly call
the ParameterNode methods such as getDefaultValue(), getParameterNumber()
etc isUnaryMinusOrPlusWithParameter() is required so that engine can catch
edge cases like select * from t1 where -? and c11=c11 or +? ie such a use of
-?/+? should be disallowed, same as what we do for ? parameters.
 Also, as mentioned in the earlier review packages, the binding code for
unary minus/unary plus dynamic parameters will not be executed until the
type of these parameters can be determined. The type gets detemined when the
setType method is called. For this reason, setType method is overridden in
UnaryArithmeticOperatorNode. After setting the type, this method calls the
binding code to make sure all the bind time rules are enforced.
 I have also consolidated the 2 type setting methods into one, namely
setType. This setType is overwritten in ParameterNode so it can also set the
type in the array of parameter types in StatementNode. Hopefully, this will
make the type setting code much cleaner.
 I have added several new tests to check this functionality and these tests
are in unaryArithmeticDynamicParameter.java. The test will get run in both
embedded and network server modes.
 svn stat
M java\engine\org\apache\derby\impl\sql\compile\CastNode.java
M java\engine\org\apache\derby\impl\sql\compile\ResultSetNode.java
M java\engine\org\apache\derby\impl\sql\compile\TernaryOperatorNode.java
M
java\engine\org\apache\derby\impl\sql\compile\HasVariantValueNodeVisitor.java
M java\engine\org\apache\derby\impl\sql\compile\ParameterNode.java
M java\engine\org\apache\derby\impl\sql\compile\LikeEscapeOperatorNode.java
M java\engine\org\apache\derby\impl\sql\compile\Predicate.java
M java\engine\org\apache\derby\impl\sql\compile\BinaryOperatorNode.java
M
java\engine\org\apache\derby\impl\sql\compile\StaticClassFieldReferenceNode.java
M java\engine\org\apache\derby\impl\sql\compile\MethodCallNode.java
M java\engine\org\apache\derby\impl\sql\compile\SelectNode.java
M java\engine\org\apache\derby\impl\sql\compile\SubqueryNode.java
M java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java
M java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java
M java\engine\org\apache\derby\impl\sql\compile\ColumnDefinitionNode.java
M
java\engine\org\apache\derby\impl\sql\compile\UnaryArithmeticOperatorNode.java
M java\engine\org\apache\derby\impl\sql\compile\ConditionalNode.java
M java\engine\org\apache\derby\impl\sql\compile\TimestampOperatorNode.java
M
java\engine\org\apache\derby\impl\sql\compile\SimpleStringOperatorNode.java
M java\engine\org\apache\derby\impl\sql\compile\JoinNode.java
M java\engine\org\apache\derby\impl\sql\compile\SQLToJavaValueNode.java
M
java\engine\org\apache\derby\impl\sql\compile\BinaryRelationalOperatorNode.java
M java\engine\org\apache\derby\impl\sql\compile\HashJoinStrategy.java
M java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
M java\engine\org\apache\derby\impl\sql\compile\IsNullNode.java
M java\engine\org\apache\derby\impl\sql\compile\SetOperatorNode.java
M java\engine\org\apache\derby\impl\sql\compile\ValueNodeList.java
M java\engine\org\apache\derby\impl\sql\compile\JavaValueNode.java
M java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj
M java\engine\org\apache\derby\impl\sql\compile\CoalesceFunctionNode.java
M java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java
M
java\engine\org\apache\derby\impl\sql\compile\BinaryLogicalOperatorNode.java
M java\engine\org\apache\derby\impl\sql\compile\LengthOperatorNode.java
M
java\engine\org\apache\derby\impl\sql\compile\ConcatenationOperatorNode.java
M java\engine\org\apache\derby\impl\sql\compile\UnaryOperatorNode.java
M java\engine\org\apache\derby\impl\sql\compile\PredicateList.java
M java\engine\org\apache\derby\impl\sql\compile\BinaryListOperatorNode.java
M java\engine\org\apache\derby\impl\sql\compile\NonStaticMethodCallNode.java
M java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
M java\engine\org\apache\derby\impl\sql\compile\ValueNode.java
M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
M java\engine\org\apache\derby\impl\sql\compile\StaticMethodCallNode.java
M java\engine\org\apache\derby\iapi\sql\compile\OptimizablePredicate.java
M java\engine\org\apache\derby\iapi\sql\compile\JoinStrategy.java
M java\testing\org\apache\derbyTesting\functionTests\tests\lang\build.xml
A
java\testing\org\apache\derbyTesting\functionTests\tests\lang\unaryArithmeticDynamicParameter.java
A
java\testing\org\apache\derbyTesting\functionTests\master\unaryArithmeticDynamicParameter.out
M java\testing\org\apache\derbyTesting\functionTests\suites\derbylang.runall
M
java\testing\org\apache\derbyTesting\functionTests\suites\derbynetmats.runall

The patch is attached to the JIRA entry. As always, any feedback will be
very appreciated.
Mamta
 On 10/6/05, Daniel John Debrunner <djd@debrunners.com> wrote:
>
> Mamta Satoor wrote:
> > 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?
>
> Sounds good, the method now (almost) matches the way it is used, rather
> than overloading isParameterNode for multiple meanings.
>
> One small change might be to call the method 'requiresTypeFromContext()'
> as 'getsTypeFromContext()' could read that the node itself fetches its
> type from its context.
>
> Dan.
>
>
>

Mime
View raw message