You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by "Kenneth Knowles (JIRA)" <ji...@apache.org> on 2017/05/23 21:07:04 UTC
[jira] [Commented] (BEAM-2353) FileNamePolicy context parameters
allow backwards compatibility where we really don't want any
[ https://issues.apache.org/jira/browse/BEAM-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021865#comment-16021865 ]
Kenneth Knowles commented on BEAM-2353:
---------------------------------------
Added to version 2.1.0 because it is breaking and we should make it ASAP.
> FileNamePolicy context parameters allow backwards compatibility where we really don't want any
> ----------------------------------------------------------------------------------------------
>
> Key: BEAM-2353
> URL: https://issues.apache.org/jira/browse/BEAM-2353
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-core
> Reporter: Kenneth Knowles
> Assignee: Reuven Lax
> Fix For: 2.1.0
>
>
> Currently, in {{FileBasedSink}} the {{FileNamePolicy}} object accepts parameters of type {{Context}} and {{WindowedContext}} respectively.
> These contexts are a coding technique to allow easy backwards compatibility when adding new parameters. However, if a new parameter is added to the file name policy it is likely data loss for the user to not incorporate it, so in fact that is never a safe backwards compatible change.
> These are brand-new APIs and marked experimental. This is important enough I think we should make the breaking change.
> We should inline all the parameters of the context, so that we _cannot_ add parameters and maintain compatibility. Instead, if we have new ones we want to add, it will have to be a new method or some such.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)