You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Zoltan Haindrich (JIRA)" <ji...@apache.org> on 2018/10/18 12:42:00 UTC

[jira] [Comment Edited] (CALCITE-2632) Add hashCode and equals implementations to RexNode

    [ https://issues.apache.org/jira/browse/CALCITE-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16655171#comment-16655171 ] 

Zoltan Haindrich edited comment on CALCITE-2632 at 10/18/18 12:41 PM:
----------------------------------------------------------------------

I right now think that either of the following could improve the situation:

* use {{toString()}} in RexNode equals/hashCode methods - this is the way rexsimplify is doing it so far...this would enable to use sets/etc
* add an assert or exception to {{RexNode.hashCode/equals}} - which would force every subclass to really implement it



was (Author: kgyrtkirk):
I right now see to better options to the situation right now:

* use {{toString()}} in RexNode equals/hashCode methods - this is the way rexsimplify is doing it so far...this would enable to use sets/etc
* add an assert or exception to {{RexNode.hashCode/equals}} - which would force every subclass to really implement it


> Add hashCode and equals implementations to RexNode 
> ---------------------------------------------------
>
>                 Key: CALCITE-2632
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2632
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Zoltan Haindrich
>            Assignee: Zoltan Haindrich
>            Priority: Major
>
> Right now RexNode doesn't have any equals or hashCode functions; which makes it rely on the default implementation.
> But when we are writing simplification logics we sometimes forget to use {{toString()}} during comparisions and may try to rely on pure equals:
> * there is a [Set of RexNode-s|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1104] during {{AND}} simplification and in [RexUtil as well|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L321]
> * I've by mistake just written rexNode.equals(otherRexNode) during the implementation of CALCITE-1413
> * I've just bumped into the same thing...that [RexUtil.andNot|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L1888] is also rely on it....and I think those comparisions go back a while (~3years at least) ; and a bug is not appeared from it because this comparision is in most cases false.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)