[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770727#action_12770727
]
Dag H. Wanvik commented on DERBY-4421:
--------------------------------------
I think the regular structure provided by the empty method, and the saved code in nodes with
no kids, is the stronger argument here. I noticed similar advantages when working with treePrint/printSubNodes.
The usage pattern should be clearly documented in QTN, though, since it is slight less intuitive.
> Allow Visitors to process the nodes bottom-up
> ---------------------------------------------
>
> Key: DERBY-4421
> URL: https://issues.apache.org/jira/browse/DERBY-4421
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d4421-1a.diff, d4421-1a.stat
>
>
> Currently, QueryTreeNode.accept() walks the tree top-down, always calling
> visit() on the parent before it calls visit() on the children. Although this
> is fine in most cases, there are use cases where visiting the nodes
> bottom-up would be better. One example is mentioned in DERBY-4416. The
> visitor posted there looks for binary comparison operators and checks
> whether both operands are constants. If they are, the operator is replaced
> with a boolean constant.
> Take this expression as an example: (1<2)=(2>1)
> The query tree looks like this:
> =
> / \
> / \
> < >
> / \ / \
> / \ / \
> 1 2 2 1
> If we walk the tree top-down with the said visitor, the = node doesn't have
> constant operands when it's visited. The < and > operators do have constant
> operands, and they're both replaced with constant TRUE. This means the
> expression (1<2)=(2>1) is rewritten to TRUE=TRUE, and that's how far the
> transformation goes.
> If the tree had been processed bottom-up, we would start with the < and >
> operators, and again replace them with TRUE. The query tree would therefore
> have been transformed to this intermediate form when the = operator was
> visited:
> =
> / \
> / \
> TRUE TRUE
> This is the same as the end result when visiting top-down, but now the =
> operator hasn't been visited yet. Since both the operands of the = operator
> are constants, the visitor will perform yet another transformation so the
> tree is simplified further and ends up as:
> TRUE
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
|