[GitHub] [calcite] rubenada commented on issue #1110: [CALCITE-2920] RelBuilder: new method to create an antijoin (Ruben Quesada Lopez)

[GitBox <gi...@apache.org>]

rubenada commented on issue #1110: [CALCITE-2920] RelBuilder: new method to create an antijoin (Ruben Quesada Lopez)
URL: https://github.com/apache/calcite/pull/1110#issuecomment-475321766
 
 
   Following the comment by @julianhyde in the Jira ticket, I think we could be a bit more ambitious with this PR and build a "true AntiJoin relational expression"; so I'd propose the following:
   - Modify `SemiJoin` class: add a new instance field `protected final SemiJoinType semiJoinType;`, which will be by default `SemiJoinType.SEMI` (to ensure backwards compatibility); but that could also be `SemiJoinType.ANTI`, to represent an AntiJoin (a.k.a. AntiSemiJoin)
   - We could easily have two implementations of Antijoin:
   a) Enumerable: small modification in `EnumerableSemiJoin` and `EnumerableSemiJoinRul`e in order to propagate the `SemiJoinType`, plus a new antiJoin method in `EnumerableDefaults` (basically the same as semiJoin method, but with a "not contains" predicate instead of "contains")
   b) Correlate: small modification in `JoinToCorrelateRule` to propagate the `SemiJoin.semiJoinType` will suffice to create the appropriate `LogicalCorrelate` with type SEMI / ANTI
   - RelBuilder antiJoin method would no longer create a `LogicalCorrelate` type=ANTI, but instead a `SemiJoin` type=ANTI (using a new method in `SemiJoinFactory` that would accept an additional `SemiJoinType` parameter).
   What do you think?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services