Hello Calcite devs,

Our team currently has a setup in which we have a single TableScan
implementation (e.g. MyTableScan) serving multiple Calcite tables. Each
MyTableScan handles the registration of rules tailored to its respective
Calcite table. I've included an example of the code structure at the end of
my email.

What we’ve run into is the class-based deduplication behaviour here
<https://github.com/apache/calcite/blob/351ddeb47b8dfb5c196c563920290a79575e9864/core/src/main/java/org/apache/calcite/plan/AbstractRelOptPlanner.java#L235>,
meaning only one instance of MyTableScan can successfully register its
rules.

We’re exploring solutions to split these such that each table has a unique
TableScan implementation, but also wanted to check first: is there any
alternate way we could keep the single class approach, but still have
Calcite register each MyTableScan?

Best,
Austin


---


Example code structure:


abstract class MyTable {
    abstract RelOptRule getRule();

    @Override
    public RelNode toRel(...) {
        return new MyTableScan(getRule());
    }
}

...

class Table1 extends MyTable {
    @Override
    RelOptRule getRule() { ... }
}

...

class Table2 extends MyTable {
    @Override
    RelOptRule getRule() { ... }
}

...

class MyTableScan {
    RelOptRule rule;

    // ... constructor where rule is injected ...

    @Override
    public void register(RelOptPlanner planner) {
        planner.addRule(rule);
    }
}

Reply via email to