flink-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kostas Kloudas <k.klou...@data-artisans.com>
Subject Re: CEP join across events
Date Fri, 28 Apr 2017 08:06:30 GMT
Hi Elias,

I think this is a really interesting suggestion for the case where you do not have an “accumulating”

value. Because imagine that you want to accept the “next” element, if the sum of all the
previous 
is less than Y. To have a similar syntax with an accumulator, we should add more methods with

additional arguments, right? 

For a first release, we opted for the simplest solution so that we can gather more information
on 
how people intend to use the new features. Despite that, I really think that it is an interesting
and 
more intuitive syntax so could you open a JIRA so that we move the discussion there, or if
you 
want I can open it for you.

Thanks a lot for the suggestion,
Kostas

> On Apr 28, 2017, at 1:09 AM, Elias Levy <fearsome.lucidity@gmail.com> wrote:
> 
> It would be useful if there were a cleaner syntax for specifying relationships between
matched events, as in an SQL join, particularly for conditions with a quantifier of one.
> 
> At the moment you have to do something like
> 
>     Pattern.
>       .begin[Foo]("first")
>         .where( first => first.baz == 1 )
>       .followedBy("next")
>         .where({ (next, ctx) =>
>           val first = ctx.getEventsForPattern("first").next
>           first.bar == next.bar && next => next.boo = "x"
>         })
> 
> which is not very clean.  It would friendlier if you could do something like:
> 
>     Pattern.
>       .begin[Foo]("first")
>         .where( first => first.baz == 1 )
>       .followedBy("next")
>         .relatedTo("first", { (first, next) => first.bar == next.bar })
>         .where( next => next.boo = "x" )
> 
> 
> 
> On Thu, Apr 27, 2017 at 1:21 AM, Kostas Kloudas <k.kloudas@data-artisans.com <mailto:k.kloudas@data-artisans.com>>
wrote:
> Glad that this is not a blocker for you and 
> you are right that we should clarify it better in the documentation.
> 


Mime
View raw message