[
https://issues.apache.org/jira/browse/FLINK-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428447#comment-15428447
]
ASF GitHub Bot commented on FLINK-3703:
---------------------------------------
Github user tillrohrmann commented on the issue:
https://github.com/apache/flink/pull/2367
Thanks for your contribution and apologies for the late review @mushketyk.
I think your implementation goes into the right direction and I really like the
testing.
I think what we still can and should improve is to pull out the
`MatchingBehaviour` out of the `SharedBuffer` and the `State`. The `NFA` should
be the only component which is responsible for the matching behaviour. I think
we can achieve this if we pimp the `SharedBuffer` a little bit.
So what should roughly happen is that the `NFA` removes computation states
which are not longer valid. Furthermore, we have to clean up the `SharedBuffer`
and remove `SharedBufferEntries` which depend on other `SharedBufferEntries`
which are no longer valid (e.g. due to `MatchingBehaviour.afterLast`).
So when you have a `SharedBufferEntry` representing a certain state which
is part of the currently matched sequence and `MatchingBehaviour.afterLast`,
then you have to find out all `SharedBufferEntries` which depend on this state
(children) and remove them. That you have to do until you reach the youngest
descendant. Currently we can only find the predecessors for a given
`SharedBufferEntry` but not the children. I think that would have to be added
in order to implement the different `MatchingBehaviours`.
> Add sequence matching semantics to discard matched events
> ---------------------------------------------------------
>
> Key: FLINK-3703
> URL: https://issues.apache.org/jira/browse/FLINK-3703
> Project: Flink
> Issue Type: Improvement
> Components: CEP
> Affects Versions: 1.0.0, 1.1.0
> Reporter: Till Rohrmann
> Assignee: Ivan Mushketyk
> Priority: Minor
>
> There is no easy way to decide whether events can be part of multiple
> matching sequences or not. Currently, the default is that an event can
> participate in multiple matching sequences. E.g. if you have the pattern
> {{Pattern.<Event>begin("a").followedBy("b")}} and the input event stream
> {{Event("A"), Event("B"), Event("C")}}, then you will generate the following
> matching sequences: {{Event("A"), Event("B")}}, {{Event("A"), Event("C")}}
> and {{Event("B"), Event("C")}}.
> It would be useful to allow the user to define where the matching algorithm
> should continue after a matching sequence has been found. Possible option
> values could be
> * {{from first}} - continue keeping all events for future matches (that is
> the current behaviour)
> * {{after first}} - continue after the first element (remove first matching
> event and continue with the second event)
> * {{after last}} - continue after the last element (effectively discarding
> all elements of the matching sequence)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
