Github user yestinchen commented on the issue:
https://github.com/apache/flink/pull/4331
@dawidwys Thanks for the reviewing.
Problem 1 is easy to fix, we can just start a new match process if the only
left computation state reaches stopState.
Problem 2 can not be avoided with current approach. It's impossible to
know whether there are potential matches.
I think the best wary to implement this correctly is try to start a new
match process after processing each event, and discard unfinished match process
after a successful match according to the skip strategy. In order to do that,
we need to keep the logical order of the events, which is the original idea I
proposed.
As for your general notes, I have some ideas:
1. I agree that the Oracle's specification is designed for bounded data.
But match recoginize in unbounded data is very similar to bounded data, since
all data are being processed one by one, and there's no need for bound
information. As for **_empty match_** , I think we can just use Oracle's
definition.
> Some patterns permit empty matches. For example:
PATTERN (A*)
can be matched by zero or more rows that are mapped to A.
An empty match does not map any rows to primary row pattern variables;
nevertheless, an empty match has a starting row. For example, there can be an
empty match at the first row of a row pattern partition, an empty match at the
second row of a row pattern partition, etc. An empty match is assigned a
sequential match number, based on the ordinal position of its starting row, the
same as any other match.
2. I feel uncomfortable with the RuntimeExceptions too. But these
exceptions are very important to keep the skip semantics right. I understand
your main concern is that Exceptions will stop the matching process, which is
unacceptable to online streaming service. To address this, I think we can
introduce a default strategy(SKIP_TO_NEXT_EVENT, for example). If these
exceptions happens, we can use default strategy to continue the match process,
and change the strategy back after a successful match. We can also add a switch
to let user decide whether to enable this feature.
3. I still think it's useful to support these skip strategies. Don't know
why Esper does not support them.
4. Thanks for the related information. I took a brief look at the PR, which
is very similar to this PR. I wonder why it is closed without merging into the
master code?
Looking forward to your feedbacks. Thanks.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
