[jira] [Comment Edited] (FLINK-7479) Support to retrieve the past event by physical offset

["Dian Fu (JIRA)" <ji...@apache.org>]

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

Dian Fu edited comment on FLINK-7479 at 8/19/17 2:27 AM:
---------------------------------------------------------

Hi [~kkl0u], 
Thanks a lot for your reply.
{quote}
Before opening a PR for a feature, we first have to discuss iff we want to include that feature in the library. 
If we do not go like this, then the only thing that will happen is that we pile up PRs that we do not know how to handle at the end.
{quote}
Agree. I will create the PR until we agree on the feature next time. Thanks for remind. :)

{quote}
I have not looked at the code itself, but from the topic, this just seems to just be syntactic sugar on top of the existing APIs.
{quote}
I don't think so. The tests in the PR can show that it's not able to achieve this functionality on top of the existing APIs.

{quote}
Until users start using the library and ask for features, and given that this is a first iteration of the CEP/SQL integration, 
I would suggest to keep it to a minimal and avoid stuff that only contribute "facilitation methods" for already existing functionality.
{quote}
Totally agree. I will try to keep the CEP/SQL integration feature a minimal and only adding features when required.  For the {{PREV}} clause, I think it should be included in the minimal feature as it's one important building block for pattern defination.


was (Author: dian.fu):
Hi [~kkl0u], 
{quote}
Before opening a PR for a feature, we first have to discuss iff we want to include that feature in the library. 
If we do not go like this, then the only thing that will happen is that we pile up PRs that we do not know how to handle at the end.
{quote}
Agree. I will create the PR until we agree on the feature next time. Thanks for remind. :)

{quote}
I have not looked at the code itself, but from the topic, this just seems to just be syntactic sugar on top of the existing APIs.
{quote}
I don't think so. The tests in the PR can show that it's not able to achieve this functionality on top of the existing APIs.

{quote}
Until users start using the library and ask for features, and given that this is a first iteration of the CEP/SQL integration, 
I would suggest to keep it to a minimal and avoid stuff that only contribute "facilitation methods" for already existing functionality.
{quote}
Totally agree. I will try to keep the CEP/SQL integration feature a minimal and only adding features when required.  For the {{PREV}} clause, I think it should be included in the minimal feature as it's one important building block for pattern defination.

> Support to retrieve the past event by physical offset 
> ------------------------------------------------------
>
>                 Key: FLINK-7479
>                 URL: https://issues.apache.org/jira/browse/FLINK-7479
>             Project: Flink
>          Issue Type: Sub-task
>          Components: CEP, Table API & SQL
>            Reporter: Dian Fu
>            Assignee: Dian Fu
>
> Currently, it's already able to retrieve events matched to the specifed pattern in {{IterativeCondition.Context}}. While there are also requirements to retrieve events by an physical offset. The retrieved events may not be matched to any pattern.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)