Joe/All,
Thank you for the thoughtful answers and great discussion. I have not
tried version controlled flows, but it sounds like that would suit my
use-case best. So, if it works like a flow class, as you described, how
do the many instances of the versioned flow get updated when changes are
So I think we have a lot of different concepts going on here. I’ll try to
provide my thoughts on each one as I’ve spent a good bit of timing thinking
about each of them over the last year or two :)
Wormhole connections: these would be very nice to have because it would allow
us to avoid having
IMO the concept of "functions" is different enough to warrant its own
set of components, rather than trying to shoehorn them into a wormhole
/ PG discussion. Perhaps a Function component which may feel like a PG
(but with UI distinction such as rounded corners?), but would be
referred to by name
Joe, Aldrin,
Wormholes is pretty interesting thing. I played around with that and could
make it working. Though, this approach has downsides.
I'll create an article for this, but you can take a look at it now
(attaching template for root canvas).
So, what I've found while playing around this
@Joe @Matt
This is kinda related to the point that Joe made in the graph DB thread
about provenance. My thought here was that we need some standards on
enriching the metadata about what was fetched so that no matter how you
store the provenance, you can find some way to query it for questions
I think what you highlighted is kind of how I had it worked out in my
mind. Although maybe I read too much into the description of the proposal
about the framework managing context. In terms of what we have now, I
think I pictured this to be "Tag this data as from this source" and then
when
Aldrin
Referencable groups would have to work like a single instance of a PG in
terms of flow definition but caller specific instances in reality.
Otherwise youd have no way to avoid cross contaminating flowfiles from
various callers as thered be no caller specific stack (in our case caller
I think the Registry solves part of the issue but even that would lead to
duplication of units where we are "copying and pasting" the "code."
Versioning would aid in keeping all components in lock step, but will not
remedy manual intervention with n-many instances of them. After one was
altered,
