[
https://issues.apache.org/jira/browse/FLINK-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060679#comment-16060679
]
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_r123715389
--- Diff: docs/dev/libs/cep.md ---
@@ -334,6 +334,20 @@ pattern.where(event => ... /* some condition
*/).or(event => ... /* or condition
</div>
</div>
+
+**Stop condition:** In case of kleene operators (`oneOrMore()` and
`oneOrMore().optional()`) you can
+also specify a stop condition, e.g. accept events with value larger than 5
until the sum of values is smaller than 50.
--- End diff --
In general, I would not use the "kleene" term, as we do not use it
throughout the rest of the docs.
You can say sth like "looping" or simply oneOrMore.
In addition, it would also be more consistent to not use "operator" but
"pattern". In the docs we have "pattern sequences" composed of "patterns" so we
should stick to that.
So "Kleene Operator" -> "looping pattern" or "oneOrMore pattern"
> 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)
