It is important that the digest is not unique. We want to identify RelNodes 
that are different objects but have identical content. Such RelNodes will have 
identical digests. Then we can combine these into one when we register them in 
a Volcano planner.


> On Aug 8, 2017, at 10:55 AM, Hanumath Rao Maduri <hanu....@gmail.com> wrote:
> 
> Hello All,
> 
> I was looking at a bug (in Apache Drill) where in a join query with table
> options with different configurations but having same table name is causing
> a NULL pointer exception. In the case of the table function it preprocesses
> and converts the TranslatableTable to DrillScanRel (here it is a subclass
> of AbstractRelNode).
> 
> Please do not worry about Drill specific nodes here. However during the
> HepPlanning phase drill calls setRoot
> 
>    public void setRoot(RelNode rel) {
>        this.root = this.addRelToGraph(rel);
>        this.dumpGraph();
>    }
> 
> This prepares the graph. But during debugging this code what I observed is
> the
> 
> AbstractRelNode.java
> 
>  public String recomputeDigest() {
>    String tempDigest = computeDigest();
>    assert tempDigest != null : "post: return != null";
>    String prefix = "rel#" + id + ":";
> 
>    // Substring uses the same underlying array of chars, so saves a bit
>    // of memory.
>    this.desc = prefix + tempDigest;
>    this.digest = this.desc.substring(prefix.length());
>    return this.digest;
>  }
> 
> 
> original value for digest is assigned as follows
>    this.digest = getRelTypeName() + "#" + id;
> 
> This is unique because id value is unique wheres in recomputeDigest digest
> will not be unique as this.desc.substring(prefix.length()) is skipping the
> id part
> 
> 
> I am not sure as to whether is this an issue. I could fix the particular
> drill case by overriding the recomputeDigest in DrillScanRel.
> 
> 
> Please advise me if this is an issue at the calcite code.
> 
> 
> Thanks,
> -Hanu

Reply via email to