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 >
