[
https://issues.apache.org/jira/browse/FLINK-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15944735#comment-15944735
]
ASF GitHub Bot commented on FLINK-6197:
---------------------------------------
Github user dawidwys commented on a diff in the pull request:
https://github.com/apache/flink/pull/3624#discussion_r108355802
--- Diff:
flink-libraries/flink-cep/src/main/java/org/apache/flink/cep/nfa/NFA.java ---
@@ -553,9 +559,38 @@ private int calculateIncreasingSelfState(int
ignoreBranches, int takeBranches) {
return outgoingEdges;
}
+ private boolean checkFilterCondition(ComputationState<T>
computationState, IterativeCondition<T> condition, T event) throws Exception {
+ return condition == null || condition.filter(event,
computationState.getConditionContext());
+ }
+
+ Map<String, List<T>> extractCurrentMatches(final ComputationState<T>
computationState) {
+ if (computationState.getPreviousState() == null) {
+ return new HashMap<>();
+ }
+
+ Collection<LinkedHashMultimap<String, T>> paths =
stringSharedBuffer.extractPatterns(
+ computationState.getPreviousState().getName(),
+ computationState.getEvent(),
+ computationState.getTimestamp(),
+ computationState.getVersion());
- private boolean checkFilterCondition(FilterFunction<T> condition, T
event) throws Exception {
- return condition == null || condition.filter(event);
+ // for a given computation state, we cannot have more than one
matching patterns.
+ Preconditions.checkArgument(paths.size() <= 1);
--- End diff --
How about checkState?
> Add support for iterative conditions.
> -------------------------------------
>
> Key: FLINK-6197
> URL: https://issues.apache.org/jira/browse/FLINK-6197
> Project: Flink
> Issue Type: Bug
> Components: CEP
> Affects Versions: 1.3.0
> Reporter: Kostas Kloudas
> Assignee: Kostas Kloudas
> Fix For: 1.3.0
>
>
> So far, the {{where}} clause only supported simple {{FilterFunction}}
> conditions.
> With this, we want to add support for conditions where the an event is
> accepted not only based on its own properties, e.g. name, as it was before,
> but also based on some statistic computed over previously accepted events in
> the pattern, e.g. if the price is higher than the average of the prices of
> the previously accepted events.
> This in combination with the recently added quantifiers will allow for a lot
> more expressive patterns.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)