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 "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2009/10/23 13:19:59 UTC
[jira] Created: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
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
Priority: Minor
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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771451#action_12771451 ]
Dag H. Wanvik commented on DERBY-4421:
--------------------------------------
+1 to centralizing the stopTraversal check.
> 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, d4421-2a.diff, d4421-2a.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.
[jira] Updated: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4421:
--------------------------------------
Issue & fix info: [Patch Available]
> 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, d4421-2a.diff, d4421-2a.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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Bryan Pendleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770515#action_12770515 ]
Bryan Pendleton commented on DERBY-4421:
----------------------------------------
Thanks Knut for taking the time to work through the details. I think this is a good
change and I'm excited about the improved optimization behaviors!
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Bryan Pendleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770116#action_12770116 ]
Bryan Pendleton commented on DERBY-4421:
----------------------------------------
I think Rick may have been asking whether QueryTreeNode.acceptChildren should
be abstract. For which sub-classes of QueryTreeNode is the empty implementation
of acceptChildren correct as is?
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770972#action_12770972 ]
Dag H. Wanvik commented on DERBY-4421:
--------------------------------------
I checked the Javadoc on QTN.acceptChildren, I think it is fine.
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770485#action_12770485 ]
Knut Anders Hatlen commented on DERBY-4421:
-------------------------------------------
Committed d4421-1a.diff with revision 830154.
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770032#action_12770032 ]
Rick Hillegas commented on DERBY-4421:
--------------------------------------
Thanks for the patch, Knut. Looks good. A couple comments:
1) Why does acceptChildren() have package access rather than public or protected access?
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.
Thanks,
-Rick
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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
QueryTreeNode?
> 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.
[jira] Closed: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen closed DERBY-4421.
-------------------------------------
> 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
> Fix For: 10.6.0.0
>
> Attachments: d4421-1a.diff, d4421-1a.stat, d4421-2a.diff, d4421-2a.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.
[jira] Updated: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4421:
--------------------------------------
Attachment: d4421-2a.stat
d4421-2a.diff
Attaching patch 2a which removes the now redundant calls to stopTraversal() in acceptChildren(). The calls are redundant because QTN.accept() always checks stopTraversal() before calling visit(). I found a couple of instances where subclasses had forgotten to check stopTraversal(), so I believe the centralized check in QTN.accept() is more robust than relying on each subclass to check it.
All the regression tests ran cleanly.
> 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, d4421-2a.diff, d4421-2a.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.
[jira] Updated: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4421:
--------------------------------------
Attachment: d4421-1a.stat
d4421-1a.diff
Attached is a patch with the following code changes:
1) Adds a method visitChildrenFirst() to the Visitor interface and implements it as "return false" for all existing visitor classes.
2) QueryTreeNode.accept() checks visitChildrenFirst() to see if visit() should be called on the parent or the children first.
3) Makes QueryTreeNode.accept() final to prevent sub-classes from overriding it, as classes that override it would need to duplicate the logic. Duplicated code tends to be more difficult to maintain and more error-prone and should be avoided.
4) Adds an empty acceptChildren() method to QueryTreeNode. This method is called by QueryTreeNode.accept(), and sub-classes should now override this method instead of accept().
5) Replaces all accept() overrides in sub-classes of QueryTreeNode with acceptChildren().
Most of these steps were just mechanical transformations. There's one exception from the rule: FromList.accept() was removed instead of replaced with an acceptChildren() method. That's because the old accept() method did the exact same thing as the parent's (QueryTreeNodeVector) accept() method did. This worked, and didn't cause nodes to be visited twice, because FromList.accept() didn't follow the established pattern and call super.accept(). There's however no reason to implement accept() or acceptChildren() in FromList, so I found it more consistent to remove it.
The patch removes more code than it adds (215 lines added, 359 lines removed), so I think it's a good clean-up. Since the checking of Visitor.stopTraversal() has been centralized to QueryTreeNode.accept(), we could also remove the now redundant calls to stopTraversal() in all the acceptChildren() methods. But I'd prefer to do that in a follow-up patch in order to keep this patch smaller and easier to understand.
The regression tests ran cleanly with an earlier version of the patch. The patch had to be refreshed because DERBY-3634 has added one new visitor and two new accept() methods after that. Rerunning regression tests now.
I also tested the patch together with the patch from DERBY-4416. If the visitor is told to traverse the tree bottom-up, the patch is now able to optimize away an WHERE clause that contains (1=1)=(1=1), so that no project-restrict result set is generated for this statement:
SELECT * FROM T WHERE (1=1)=(1=1)
Without this patch, there would be a project-restrict result set on top of the table scan with a (TRUE=TRUE) restriction.
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769189#action_12769189 ]
Knut Anders Hatlen commented on DERBY-4421:
-------------------------------------------
I propose that we add a method to the Visitor interface to control whether the visitor should visit parents or children first:
/**
* Method that is called to see if {@code visit()} should be called on
* the children of {@code node} before it is called on {@code node} itself.
* If this method always returns {@code true}, the visitor will walk the
* tree bottom-up. If it always returns {@code false}, the tree is visited
* top-down.
*
* @param node the top node of a sub-tree about to be visited
* @return {@code true} if {@code node}'s children should be visited
* before {@code node}, {@code false} otherwise
*/
boolean visitChildrenFirst(Visitable node);
QueryTreeNode.accept() must be changed to check the return value of this method, and all the existing visitors must implement the method (should return false, since all the current visitors walk the tree top-down).
> 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
> Priority: Minor
>
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769321#action_12769321 ]
Dag H. Wanvik commented on DERBY-4421:
--------------------------------------
+1.
> 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
> Priority: Minor
>
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770824#action_12770824 ]
Knut Anders Hatlen commented on DERBY-4421:
-------------------------------------------
Dag, when you say that the pattern should be clearly documented in QTN, did you have something else in mind than the current javadoc for QTN.acceptChildren()? It currently says that all overrides should call super.acceptChildren(), but I could make the comment more verbose if you think that's appropriate.
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-4421.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.6.0.0
Issue & fix info: (was: [Patch Available])
Committed patch 2a with revision 831244.
This concludes the planned work on this issue, so I'm marking it as resolved.
> 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
> Fix For: 10.6.0.0
>
> Attachments: d4421-1a.diff, d4421-1a.stat, d4421-2a.diff, d4421-2a.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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769224#action_12769224 ]
Rick Hillegas commented on DERBY-4421:
--------------------------------------
+1 to this idea.
> 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
> Priority: Minor
>
> 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.
[jira] Commented: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770477#action_12770477 ]
Knut Anders Hatlen commented on DERBY-4421:
-------------------------------------------
I didn't check all the nodes (QueryTreeNode has 159 sub-classes), but here are some examples on classes that should have an empty implementation of acceptChildren() because they have no visitable children:
UserTypeConstantNode
SQLBooleanConstantNode
UntypedNullConstantNode
BitConstantNode
XMLConstantNode
BooleanConstantNode
VarbitConstantNode
NumericConstantNode
SpecialFunctionNode
TableName
TableElementNode
WindowReferenceNode
CurrentDatetimeOperatorNode
CurrentRowLocationNode
NOPStatementNode
SetTransactionIsolationNode
The following classes should also have an empty acceptChildren() method if they currently implement accept() correctly (they do have visitable children, though, so it might be that they actually should have had a non-empty acceptChildren() method):
GenerationClassNode
DefaultNode
PrivilegeNode
TablePrivilegeNode
WindowDefinitionNode
BaseColumnNode
VirtualColumnNode
ParameterNode
ColumnReference
ExecSPSNode
I see the point that making acceptChildren() abstract could help us detect some cases of missing overrides. Apart from slightly reducing the amount of code needed, one advantage of having an empty method in QTN instead of an abstract method is that all the overrides will have the same structure (call super.acceptChildren() and then accept() on all added children). With the abstract method, the structure will be different depending on where in the class tree the node is located (super.acceptChildren() cannot be called if none of the super-classes implement it, but it has to be called if one of them does). This means that each time you implement an acceptChildren() method, you'll have to check all sub-classes of the node in which you implement it, and add a call to super.acceptChildren() in each of the sub-classes' implementations. This could be easy to forget.
The two approaches protect against different classes of errors, so I can be convinced either way. For now, I'll just commit the patch as it is, since most of it will stay the same regardless of which approach we choose.
> 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.
[jira] Assigned: (DERBY-4421) Allow Visitors to process the nodes
bottom-up
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen reassigned DERBY-4421:
-----------------------------------------
Assignee: Knut Anders Hatlen
> 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
>
> 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.