Obviously, three options in a drop down :-D
On Fri, Feb 9, 2024 at 7:49 AM Mike Thomsen wrote:
> How about a third option which is to provide three options:
>
> 1) Default - status quo, exceptions cause it to yield
> 2) Exception = moves forward to success w/ an error attribute, an error
> log
How about a third option which is to provide three options:
1) Default - status quo, exceptions cause it to yield
2) Exception = moves forward to success w/ an error attribute, an error log
statement that triggers a bulletin, etc to let data manages know what's
happening.
3) Exception = moves to
--Uwe
> Am 09.02.2024 um 13:50 schrieb Mike Thomsen :
>
> How about a third option which is to provide three options:
>
> 1) Default - status quo, exceptions cause it to yield
> 2) Exception = moves forward to success w/ an error attribute, an error log
> statement that triggers a bulletin,
Yes, that certainly involves a lot of effort.
I wonder whether it's a good idea to fix a possible "design flaw" with a
construct that is neither consistent nor easy to handle.
I also think the argument that you have to adjust a lot in the flow is
questionable.
With Release 2.0, so much has to
These are great ideas! I do love Adam's dynamic relationship idea over
creating a failure relationship that is auto-terminated. This would make
flow migrations in Registry and NiFi easier.
After some more pondering, I (slowly) realized that this problem affects
more than UpdateAttribute, though.
I mean, this really speaks to the principal that (in my humble opinion) All
Processors Shalt Have Failure Relationships as best practice.
So I think the decision is really, how much pain do we want to impose on
NiFi 2.0 adopters. UpdateAttribute and RouteOnAttribute are used literally
everywhere
I think that's a good approach which actually addresses the underlying
issue. Thank you Joe, Mark and all others.
As far as I know the default last resort behaviour of rollback + yield,
that a lot processors exhibit, is due to them being based on
AbstractProcessor.
Does it make sense to
Lucas
The change proposed is specific to the original intent, implementation,
evolution, and bridging to new intent for certain cases of that specific
processor.
I remain supportive of processors using the capabiltities of the api and
framework to best meet the user needs. “failure” is just a
Lots of good commentary and great focus on minimizing impact to the users
while fixing what is admittedly not the most desired behavior for some
cases as it relates to the very popular UpdateAttribute.
We do not want to enforce that all processors have failure relationships.
Presumably that
