You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The partiql-plan package has simple factory methods for creating operators via Operators.<name>, but some builder pattern is helpful too. In earlier release candidates, I had some lazy builders that accept the factory. I removed this in the transition to Java and to keep the partiql-plan package simple while things were in flux.
Here is a gist, but I recommend the calcite-style stack approach for multi-input operators. Also a shared context with the factory/catalogs would be super useful so you can write like,
val plans = PlanBuilder(ctx)
.scan("T")
.scan("S")
.join(on=eq(var("t.a"), var("s.a")
.build()
But there is a lot of hidden complexity here such as
what's in ctx? catalogs would be nice
where is "eq" coming from and how is it resolved?
are the variable names/paths parsed here?
when are variables resolved, since this still needs to lookup variables?
do you pass the factory in build(..) like the gist, or in a ctx?
how can you easily add functions without dealing with the complexity of "Function.Instance"?
Because these builders are additive, they were not included in the 1.0 release. If there's some use case, requirement, or ask then these questions can be worked through.
The text was updated successfully, but these errors were encountered:
Description
The partiql-plan package has simple factory methods for creating operators via
Operators.<name>
, but some builder pattern is helpful too. In earlier release candidates, I had some lazy builders that accept the factory. I removed this in the transition to Java and to keep the partiql-plan package simple while things were in flux.https://gist.github.com/RCHowell/4d0ac8889a0d7951bf2f7218deff28c8
Here is a gist, but I recommend the calcite-style stack approach for multi-input operators. Also a shared context with the factory/catalogs would be super useful so you can write like,
But there is a lot of hidden complexity here such as
build(..)
like the gist, or in a ctx?Because these builders are additive, they were not included in the 1.0 release. If there's some use case, requirement, or ask then these questions can be worked through.
The text was updated successfully, but these errors were encountered: