[
https://issues.apache.org/jira/browse/FLINK-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686705#comment-16686705
]
Dawid Wysakowicz commented on FLINK-8159:
-----------------------------------------
Ad. 1 Agree with that approach with adding additional abstract class. But my
original question was about using a new {{PatternSelectFunction}}, but I don't
think we should support dynamically changing it, that should be possible only
for {{IterativeCondition}}
Ad. 2 Agreed
Ad. 3 I know we could, but I don't think we should expose everything. actually
I would limit its capabilities to a minimum, e.g. prohibit state creation,
accumulators etc. This is of great importance especially for
{{IterativeCondition}}
I think as we have somewhat similar view on that issue, I think we could start
with the implementation if you are still interested ;). Also last but not least
sorry for the late response.
> Pattern(Flat)SelectFunctions should support RichFunction interface
> ------------------------------------------------------------------
>
> Key: FLINK-8159
> URL: https://issues.apache.org/jira/browse/FLINK-8159
> Project: Flink
> Issue Type: Sub-task
> Components: CEP
> Reporter: Dian Fu
> Assignee: Dian Fu
> Priority: Major
>
> {{SelectWrapper}} and {{FlatSelectWrapper}} should extends
> {{AbstractRichFucntion}} and process properly if the underlying functions
> extend RichFunction.
> Things to be very careful about:
> * backwards compatibility (we previously serialized conditions) - changes to
> those interfaces have to be done carefully
> * we want to be able to add dynamic patterns in the future, so at some point
> we have to open also on control message arrival
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
