[
https://issues.apache.org/jira/browse/NIFI-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005014#comment-16005014
]
Joseph Witt commented on NIFI-3860:
-----------------------------------
My initial reaction is similar to Brandon's. That said if I think about what
this is doing and how it relates to normal API usage and typical developer
experience relative to what my original intent was with enforcing it this way...
The original intent in enforcing it this way was to explicitly force the
developer to understand what the framework is doing here within a given
session. That is
* There is only ever one representation of the flowfile object that is
valid/active and that is the last successful against that flowfile in this
session that would manipulate its attributes
* There is only ever one representation of the flowfile content that is
valid/active and that is the last non-exceptional callback completed which
alters its content
* Any given flowfile object is immutable and therefore all operations to access
or alter content or attributes must occur exclusively through the session and
even if the developer hangs on to references inappropriately the framework can
protect itself from this.
We want the three bullets I described and this PR does not appear to violate
those. This PR appears to me to relax the enforcement of it such that the
framework will now do the more obvious thing in handling it. It will do the
intuitive/right thing while still enforcing those ideas and so with that in
mind I am supportive provided we sufficiently document this in the
ProcessSession API docs. I am, however, not complete with the review of this
so this does not constitute me throwing my +1 out yet.
> Consider relaxing the constraint that ProcessSession enforces we give it the
> most recent version of a FlowFile
> --------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-3860
> URL: https://issues.apache.org/jira/browse/NIFI-3860
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Mark Payne
>
> Currently, when we call methods on ProcessSession to access or modify a
> FlowFile, the ProcessSession will roll itself back and throw a
> FlowFileHandlingException with the message "<FlowFile> is not the most recent
> version of this FlowFile within this session". This was done to ensure that
> Processor developers ensure that they know what they are doing and always
> have the most recent version of a FlowFile. However, this comes with a few
> downsides:
> * It can result in code being complex in error-handling cases when we need to
> ensure that no matter what we hold the most recent version of a FlowFile
> * It's easy to call session.putAttribute and forget to store the most recent
> version of the FlowFile, which gets returned - this is most problematic when
> dealing with a Collection<FlowFile>.
> * We have a method for ProcessSession.read(FlowFile) that returns an
> InputStream. However, we don't have a corresponding write() method. This is
> due to the fact that once we finish writing to the FlowFile, we would have to
> return the most up-to-date version of the FlowFile and there's no way to do
> that if returning an OutputStream.
> We should consider relaxing this constraint and instead just always make use
> of the most recent version of the FlowFile, even if an older version of the
> FlowFile is passed in.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
