[
https://issues.apache.org/jira/browse/FLINK-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16662091#comment-16662091
]
Dian Fu commented on FLINK-8159:
--------------------------------
Thanks [~dawidwys] for your feedback.
1. I prefer adding an abstract class RichPattern(Flat)SelectFunction which
implements Pattern(Flat)SelectFunction for the following reasons:
1) consist with the way MapFunction/RichMapFunction and all other rich
functions take
2) there are no backwards compatibility issues at all
3) If we update Pattern(Flat)SelectFunction to
RichPattern(Flat)SelectFunction, I think the backwards compatibility issues can
not be solved at all as the old class doesn't exist yet.
2. We can create a class named WrappingRichPattern(Flat)SelectFunction and
holding an instance of it in AbstractKeyedCEPPatternOperator. When NFA updated,
we create a new RichPattern(Flat)SelectFunction, open it and set it as the
currently wrapped function.
3. The RichPattern(Flat)SelectFunction is an child class of
AbstractRichFunction and so RuntimeContext is exposed publicly.
> 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)
