Most of the complexity in MergeContent is around the bundling parameters... this processor would do no bundling, just straight pass through to the packaging library. No worries for the user about setting max package size, number of entries, number of bins, bin age, headers, footers, etc... even if they have sensible defaults in merge content, it's potentially confusing that if I want to "package" a FlowFile, what I need to do is "merge" it with itself (and ignore all the other confusing / irrelevant settings). Bypassing the bundling logic probably improves performance for this use case as well.
On Fri, Sep 8, 2023 at 9:56 AM Joe Witt <joe.w...@gmail.com> wrote: > Mike > > In user terms this makes sense to me. Id only bother with v3 or whatever is > latest. We want to dump the old code. And if there are seriously older > versions v1,v2 then nifi 1.x can be used. > > The challenge is that you end up needing some of the same complexity in > implementation and config of merge content i think. What did you have in > mind for that? > > Thanks > > On Fri, Sep 8, 2023 at 6:53 AM Michael Moser <moser...@gmail.com> wrote: > > > Devs, > > > > I can't find if this was suggested before, so here goes. With the demise > > of PostHTTP in NiFi 2.0, the recommended alternative is to MergeContent 1 > > file into FlowFile-v3 format then InvokeHTTP. What does the community > > think about supporting a new PackageFlowFile processor that is simple to > > configure (compared to MergeContent!) and simply packages flowfile > > attributes + content into a FlowFile-v[1,2,3] format? This would also > > offer a simple way to export flowfiles from NiFi that could later be > > re-ingested and recovered using UnpackContent. I don't want to submit a > PR > > for such a processor without first asking the community whether this > would > > be acceptable. > > > > Thanks, > > -- Mike > > >
