[
https://issues.apache.org/jira/browse/FLINK-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316032#comment-15316032
]
Stephan Ewen commented on FLINK-3777:
-------------------------------------
Can I revive this thread quickly?
This is one more of these "try and keep the API simple" attempts from my side...
I was wondering how important these additional methods are? After all,
initializing and releasing resource in "open" and "close" should work fine, and
in the wort case just initialize and release a few times (but still quite
coarse grained).
This addition makes the already complicated life cycle of input format even
more complicated. We already found cases where the added methods were not
handled correctly.
If the benefit of these additional methods is very small, I would be in favor
to remove them again, and make the system simpler to maintain and more robust
(less corner cases that can and will be overlooked).
Since this is not yet released in a stable release, we can still undo the
change in the next few weeks.
> Add open and close methods to manage IF lifecycle
> -------------------------------------------------
>
> Key: FLINK-3777
> URL: https://issues.apache.org/jira/browse/FLINK-3777
> Project: Flink
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.0.1
> Reporter: Flavio Pompermaier
> Assignee: Flavio Pompermaier
> Labels: inputformat, lifecycle
>
> At the moment the opening and closing of an inputFormat are not managed,
> although open() could be (improperly IMHO) simulated by configure().
> This limits the possibility to reuse expensive resources (like database
> connections) and manage their release.
> Probably the best option would be to add 2 methods (i.e. openInputformat()
> and closeInputFormat() ) to RichInputFormat*
> * NOTE: the best option from a "semantic" point of view would be to rename
> the current open() and close() to openSplit() and closeSplit() respectively
> while using open() and close() methods for the IF lifecycle management, but
> this would cause a backward compatibility issue...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
