Join operator API improvements. #206
Conversation
dmvk
force-pushed
the
join_api
branch
2 times, most recently
from
617b289 to
d9aa9ee
Compare
|
Related to #143 |
There was a problem hiding this comment.
This seems very nice, I have some minor concerns about the InnerJoin, that is not name that would be generally used, generally just Join implies InnerJoin, I'd suggest we stick to that. I also don't see much added value in RightJoin (although it might make sense when it comes to optimizations like broadcast joins, but we could solve this on the hint instead).
| import java.util.Objects; | ||
|
|
||
| @Audience(Audience.Type.CLIENT) | ||
| public class InnerJoin { |
There was a problem hiding this comment.
This operator should remain just Join.
| import java.util.Optional; | ||
|
|
||
| @Audience(Audience.Type.CLIENT) | ||
| public class RightJoin { |
There was a problem hiding this comment.
How is this implementation different from LeftJoin? Isn't this just quite expensive syntactic sugar around the same implementation with swapped arguments?
| }); | ||
| } | ||
|
|
||
| @Processing(Processing.Type.BOUNDED) |
There was a problem hiding this comment.
Why do we run these tests only for bounded datasets?
There was a problem hiding this comment.
OK, I see, the reason is probably that unbounded dataset cannot be join using global windowing. There are separate tests for windowing.
Join operator API improvements.
No description provided.