Thanks Fabian! This seems to be the way to go
On Tue, Jun 19, 2018 at 12:18 PM Fabian Hueske wrote:
> Hi Johannes,
>
> You are right. You should approach the problem with the semantics that you
> need before thinking about optimizations such as state size.
>
> The Table API / SQL offers (in
Hi Johannes,
You are right. You should approach the problem with the semantics that you
need before thinking about optimizations such as state size.
The Table API / SQL offers (in v1.5.0) two types of joins:
1) Windowed joins where each record joins with records in a time-range of
the other
Hi Fabian,
thanks for the hints, though I somehow got the feeling that I am on the
wrong track given how much code I would need to write for implementing a
"blueprint" usecase.
Would a join be more simple using the Table API? In the end it's the
classical Order & OrderPosition example, where the
Hi Johannes,
EventTimeSessionWindows [1] use the EventTimeTrigger [2] as default trigger
(see EventTimeSessionWindows.getDefaultTrigger()).
I would take the EventTimeTrigger and extend it with early firing
functionality.
However, there are a few things to consider
* you need to be aware that
Hi,
I am joining two streams with a session window and want to emit a joined
(early) result for every element arriving on one of the streams.
Currently the code looks like this:
s1.join(s2)
.where(s1.id).equalTo(s2.id)
.window(EventTimeSessionWindows.withGap(Time.minutes(15)))
// trigger(?)
