db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4421) Allow Visitors to process the nodes bottom-up
Date Mon, 26 Oct 2009 16:18:59 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770076#action_12770076

Knut Anders Hatlen commented on DERBY-4421:

Thanks for looking at the patch, Rick. My responses to your questions
follow below.

> 1) Why does acceptChildren() have package access rather than public
> or protected access?

The reason why it's not public is that it's only meant to be called
from QueryTreeNode and its subclasses. Others should access it
indirectly via the methods in the Visitable interface.

Protected access is more liberal than package access and would allow
the method to be overridden by sub-classes in other packages, but
since all the sub-classes of QueryTreeNode are in the same package, I
chose the stricter one.

> 2) As a follow-on effort, it might be good to make
> QueryTreeNode.accept() abstract in order to force node designers to
> think about how new nodes should be walked.

I'm not sure I follow you. Wouldn't that mean that the logic in
accept() would have to be duplicated in each sub-class of

> 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:
>            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:
>        =
>      /   \
>     /     \
> 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.

View raw message