Sorry, I missed the Filter(Join(..)) example. However, I still have some slight concerns of adding convention to the factory. This change would imply that the RelBuilder creates plans that are in a single convention. I believe this is true for the majority of use-cases, yet with the current API it is possible and desirable to build plans with RelNodes that are not created internally from the builder (using the push method for instance). I think that in these cases the presence of convention in the factory might be a bit misleading.
Στις Τρί, 29 Ιαν 2019 στις 10:41 μ.μ., ο/η Vladimir Sitnikov < [email protected]> έγραψε: > > That is why I think it is not enough to enforce "single convention only". > > I've sketched a draft implementation in > https://github.com/apache/calcite/pull/1019 > The idea there is to enforce that "convention of the first rule operand > should match the convention of RelBuilderFactory". > > I need to figure out why the tests went red, however I pretty much like > that approach: > * rule definition is pretty much intact. The changes are to remove Class > arguments and use simple Filter.class / Project.class. Note: I haven't > updated all the rules. It is just a scratch > * it should protect from cross-convention cycles > > Vladimir >
