Hi Vladimir,
If I understand it correctly, your concern is still about [1], right?
If it is, I think I have answered it in [2], perhaps it didn't jump into your
inbox.
I am still not convinced that enforcing derivation on all rels is the only way
to solve your concern.
If it is the other
> So the idea of keeping even internal components of Calcite "more public" is
> rather a good thing than the bad one from my point of view.
This can go two ways.
There is the type of change that I call “drill a hole” where someone requests
that an implementation detail be made public so that
Hi Alessandro,
this problem was already discussed on dev-list [1] and we have a ticket
for this [2].
My concern is that many projects use Calcite as a Lego kit: they took
internal components of Calcite and combine them for building a custom
planning and execution pipeline. And sometimes
Hello everyone,
@Vladimir, +1 on the change introducing "enforceDerive()".
@Roman, could you walk us through the limitations you found that forced you
to copy-paste the whole class?
Maybe there is some middle ground for your problem(s) too, similar in
spirit to what Vladimir proposed for the
Hi Vladimir,
+1 for making the rule driver more public. We've faced similar problems
in the downstream project. The solution was to copy and paste the
TopDownRuleDrive code with small fixes since it was not possible to
override the default behavior.
--
Roman Kondakov
On 11.02.2022 02:50,
Hi,
In the Cascades driver, it is possible to propagate the requests top-down
using the "passThrough", method and then notify parents bottom-up about the
concrete physical implementations of inputs using the "derive" method.
In some optimizers, the valid parent node cannot be created before the
