flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-6198) Update the documentation of the CEP library to include all the new features.
Date Thu, 01 Jun 2017 13:07:04 GMT

    [ https://issues.apache.org/jira/browse/FLINK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032941#comment-16032941
] 

ASF GitHub Bot commented on FLINK-6198:
---------------------------------------

Github user tzulitai commented on a diff in the pull request:

    https://github.com/apache/flink/pull/4041#discussion_r119606025
  
    --- Diff: docs/dev/libs/cep.md ---
    @@ -246,63 +333,118 @@ pattern.where(event => ... /* some condition */).or(event =>
... /* or condition
     </div>
     </div>
     
    -Next, we can append further states to detect complex patterns.
    -We can control the contiguity of two succeeding events to be accepted by the pattern.
    +##### Conditions on Contiguity
     
    -Strict contiguity means that two matching events have to be directly the one after the
other.
    -This means that no other events can occur in between. 
    -A strict contiguity pattern state can be created via the `next` method.
    +FlinkCEP supports the following forms of contiguity between consecutive events:
     
    -<div class="codetabs" markdown="1">
    -<div data-lang="java" markdown="1">
    -{% highlight java %}
    -Pattern<Event, ?> strictNext = start.next("middle");
    -{% endhighlight %}
    -</div>
    + 1. Strict Contiguity: which expects all matching events to appear strictly the one after
the other,
    + without any non-matching events in-between.
     
    -<div data-lang="scala" markdown="1">
    -{% highlight scala %}
    -val strictNext: Pattern[Event, _] = start.next("middle")
    -{% endhighlight %}
    -</div>
    -</div>
    + 2. Relaxed Contiguity: which simply ignores non-matching events appearing in-between
the matching ones.
    + 
    + 3. Non-Deterministic Relaxed Contiguity: which further relaxes contiguity by also creating
alternative
    + matches which ignore also matching events.
     
    -Non-strict contiguity means that other events are allowed to occur in-between two matching
events.
    -A non-strict contiguity pattern state can be created via the `followedBy` or `followedByAny`
method.
    +To illustrate the above with an example, a pattern sequence `a+ b` (one or more `a`s
followed by a `b`) with 
    +input `a1, c, a2, b` will have the following results:
    +
    + 1. Strict Contiguity: `a2 b` because there is `c` `a1` and `a2` so `a1` is discarded.
    +
    + 2. Relaxed Contiguity: `a1 b` and `a1 a2 b`, as `c` will get simply ignored.
    + 
    + 3. Non-Deterministic Relaxed Contiguity: `a1 b`, `a2 b` and `a1 a2 b`.
    + 
    +Contiguity conditions should be specified both within individual (looping) states but
also 
    +across states. For looping states (e.g. `oneOrMore()` and `times()`) the default is *relaxed
contiguity*. If you want 
    --- End diff --
    
    Regarding "Contiguity conditions should be specified both within individual (looping)
states but also across states".
    
    I'm not sure if it makes sense to present the detail that across states require contiguity
conditions at this part of the doc. The main reason is that this section is about "Individual
States", so the information was a bit "disruptive" when I first stumbled across it.


> Update the documentation of the CEP library to include all the new features.
> ----------------------------------------------------------------------------
>
>                 Key: FLINK-6198
>                 URL: https://issues.apache.org/jira/browse/FLINK-6198
>             Project: Flink
>          Issue Type: Sub-task
>          Components: CEP
>    Affects Versions: 1.3.0
>            Reporter: Kostas Kloudas
>            Assignee: Kostas Kloudas
>            Priority: Critical
>             Fix For: 1.3.0
>
>
> New features to include:
> * Iterative Functions
> * Quantifiers
> * Time handling
> * Migration from FilterFunction to IterativeCondition



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message