Github user MikeThomsen commented on the issue:
https://github.com/apache/nifi/pull/2448
@mattyb149 here's the use case that lead to this for the sake of discussion:
> Client has a few huge collections. Client wants to be able to fetch very
large chunks of them at a time. Client is unhappy that they have to wait for
the full query execution in order to see anything happen in the UI. Client's
non-production environments make it take a few hours of silent processing to
finally get anything to commit to the session and show up in the UI. Client's
technical folks probably would accept log statements at each iteration (where
it makes sense) to show "yeah, I'm doing something" from GetMongo.
So how about this third way that I could get done pretty quickly for 1.8...
1. Add RunMongoCollectionFetch as a no-input processor that works like the
input sources referenced by you above. It includes full query control,
progressive commits, progress attributes, etc.
2. Remove progressive commits from GetMongo, keep the option to calculate
progress attributes and either way put info logger statements (that can be
turned off) alerting that a new flowfile (or X num of them in the case of 1:1
result/flowfile config) was prepped.
---
