We should update the migration guide to describe this scenario. I can do it in just a bit if nobody else has. On Dec 22, 2015 11:51 AM, "Aldrin Piri" <[email protected]> wrote:
> Ricky, > > This was only applied to processors where they, for lack of other words, > had explicit requirements of input; either requiring or ignoring. GetFile > is one such example and the framework previously allowed users to connect > processors to anything regardless of whether or not they actually consumed > the input. The canonical example that spurred this was that of ExecuteSQL > which, at the time, did nothing unless it was provided with input. > ExecuteProcess vs ExecuteStreamCommand was another source of confusion for > a lot of new users. The intent was to have more immediate notification to > users. > > In the example you provide, the files provided by ExecuteProcess were never > actually being evaluated/consumed by the GetFile process. All that said, I > could certainly see a case where GetFile makes sense to be driven by > events, and would make for a nice improvement to that processor, thereby > also requiring the InputRequirement to be modified. However, in its > current state, input has no bearing on the triggering/operation of GetFile > and thus the move to mark such a connection as invalid. > > On Tue, Dec 22, 2015 at 11:28 AM, Ricky Saltzer <[email protected]> > wrote: > > > I noticed that in NiFi 0.4.0, a few processors (i.e. GetFile) are > annotated > > with @InputRequirement(Requirement.INPUT_FORBIDDEN), which is a little > > confusing to me. What is the reasoning for forbidding an input connection > > to processors like GetFile? There are situations where you want the > ability > > to trigger processors to execute, and an input connection is kind of the > > only way (that I know of) to control precisely when it happens. I tested > a > > simple ExecuteProcess -> GetFile flow in 0.3.0, and then did an in place > > upgrade to 0.4.0, which invalidated the flow. This change is pretty > major, > > and potentially breaks compatibility between upgrades. > > > > ricky > > >
