[
https://issues.apache.org/jira/browse/FLINK-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060678#comment-16060678
]
ASF GitHub Bot commented on FLINK-6418:
---------------------------------------
Github user kl0u commented on a diff in the pull request:
https://github.com/apache/flink/pull/4143#discussion_r123715144
--- Diff: docs/dev/libs/cep.md ---
@@ -547,18 +579,30 @@ pattern.where(event => ... /* some condition */)
<tr>
<td><strong>or(condition)</strong></td>
<td>
- <p>Adds a new condition which is ORed with an existing
one. An event can match the pattern only if it
+ <p>Adds a new condition which is ORed with an existing
one. An event can match the pattern only if it
passes at least one of the conditions:</p>
{% highlight scala %}
pattern.where(event => ... /* some condition */)
.or(event => ... /* alternative condition */)
{% endhighlight %}
</td>
</tr>
+<tr>
+ <td><strong>until(condition)</strong></td>
+ <td>
+ <p>Specifies a stop condition for kleene operator. Meaning
if event matching the given condition occurs, no more
--- End diff --
Same here for the "kleene operator".
> Support for dynamic state changes in CEP patterns
> -------------------------------------------------
>
> Key: FLINK-6418
> URL: https://issues.apache.org/jira/browse/FLINK-6418
> Project: Flink
> Issue Type: Improvement
> Components: CEP
> Affects Versions: 1.3.0
> Reporter: Elias Levy
> Assignee: Dawid Wysakowicz
>
> Flink CEP library allows one to define event pattern to match where the match
> condition can be determined programmatically via the {{where}} method. Flink
> 1.3 will introduce so-called iterative conditions, which allow the predicate
> to look up events already matched by the pattern and thus be conditional on
> them.
> 1.3 also introduces to the API quantifer methods which allow one to
> declaratively specific how many times a condition must be matched before
> there is a state change.
> Alas, there are use cases where the quantifier must be determined dynamically
> based on the events matched by the pattern so far. Therefore, I propose the
> adding of a new {{Pattern}}: {{until}}.
> Like the new iterative variant of {{where}}, {{until}} would take a predicate
> function and a context that provides access to events already matched. But
> whereas {{where}} determines if an event is accepted by the pattern,
> {{until}} determines whether is pattern should move on to the next state.
> In our particular use case, we have a pattern where an event is matched a
> number of times, but depending on the event type, the number (threshold) for
> the pattern to match is different. We could decompose the pattern into
> multiple similar patterns, but that could be inefficient if we have many such
> patterns. If the functionality of {{until}} were available, we could make do
> with a single pattern.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
