Hi Joe, No, the documentation is clear that is currently only available implementation. Since it was designed to be extendable, I was wondering if there were any example cases in which using the WholeConfigDifferentiator might not be the ideal differentiator and I should provide my own implementation. WholeConfigDifferentiator's implementation seems simple, fast, and to the point. I wasn't aware of the NiFi-Registry project so that helps me see the bigger picture.
Thanks, Jeff On Thu, Apr 20, 2017 at 10:36 AM, Joe Percivall <[email protected]> wrote: > Hello Jeff, > > Glad to hear the WholeConfigDifferentiator is working well. While it is > configurable, that is currently the only implementation. Is there a > specific place that suggests there are currently more implementations? The > documentation lists it as the only one[1]. When I wrote it up I implemented > it in such a way so that we could easily add other differentiators in the > future. One such example is once we have the NiFi-Registry in place, a > differentiator that takes advantage of whatever the uniqueness scheme that > is implemented for that. > > [1] https://github.com/apache/nifi-minifi/blob/master/ > minifi-docs/src/main/markdown/System_Admin_Guide.md# > automatic-warm-redeploy > > Joe > > On Thu, Apr 20, 2017 at 10:06 AM, Jeff Zemerick <[email protected]> > wrote: > >> Hi all, >> >> MiNiFi's WholeConfigDifferentiator along with the PullHttpChangeIngestor >> is working well for me. I see that the differentiator is configurable and >> additional implementations can be provided. Are there any examples of >> circumstances in which the using WholeConfigDifferentiator would not be the >> best choice? >> >> Thanks, >> Jeff >> > > > > -- > *Joe Percivall* > linkedin.com/in/Percivall > e: [email protected] >
