You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by dan young <da...@gmail.com> on 2020/04/22 19:04:02 UTC
UpdateAttribute processor question...
Hello,
I haven't been able to figure out if this is doable with a single
UpdateAttrbute processor, but is it possible to create an attribute that
references a different attribute you're setting in the same UpdateAttribute
processor? ie.
UpdateAttribute
a = "foo"
b = "bar"
c = ${allAttributes("a", "b"):join(" _")}
What I've been doing in the past is just have c in a downstream
UpdateAttribute....wonder if there's a better way of doing this, or maybe
in the Advance section of the UpdateAttribute.
Regards,
Dano
Re: UpdateAttribute processor question...
Posted by Andy LoPresto <al...@apache.org>.
You might be able to wire something together using the Advanced mode and chained conditionals, but I still don’t think order is enforced there, so even with a rule of “b exists & is not empty” then “evaluate c”, it still might occur before b is defined, so it wouldn’t throw an exception but would still not provide the result you’re expecting.
Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
He/Him
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Apr 22, 2020, at 12:38 PM, Andy LoPresto <al...@apache.org> wrote:
>
> Dan,
>
> Unfortunately I don’t believe there is a way to consolidate this in a single UA processor because currently the application of the attributes is not deterministically ordered, so b may not be available when c is evaluated and applied. The current work around is to use linear dependent processors as you are doing. I do think this is a valid feature request that could be introduced in the UA processor without breaking backwards compatibility if you’re interested in filing the ticket. Changing the internal data structure of the dynamic properties to be ordered _should_ be possible, but I think currently the API doesn’t request that order so it would require a code change there, with a default practice being “order as received".
>
>
> Andy LoPresto
> alopresto@apache.org <ma...@apache.org>
> alopresto.apache@gmail.com
> He/Him
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
>> On Apr 22, 2020, at 12:04 PM, dan young <danoyoung@gmail.com <ma...@gmail.com>> wrote:
>>
>> Hello,
>>
>> I haven't been able to figure out if this is doable with a single UpdateAttrbute processor, but is it possible to create an attribute that references a different attribute you're setting in the same UpdateAttribute processor? ie.
>>
>> UpdateAttribute
>> a = "foo"
>> b = "bar"
>> c = ${allAttributes("a", "b"):join(" _")}
>>
>> What I've been doing in the past is just have c in a downstream UpdateAttribute....wonder if there's a better way of doing this, or maybe in the Advance section of the UpdateAttribute.
>>
>>
>> Regards,
>>
>> Dano
>>
>
Re: UpdateAttribute processor question...
Posted by dan young <da...@gmail.com>.
SOunds good Andy,
No biggie, I can keep on truckin' with what we've been doing. Thanx for
the insight!
Regards,
Dano
On Wed, Apr 22, 2020 at 1:38 PM Andy LoPresto <al...@apache.org> wrote:
> Dan,
>
> Unfortunately I don’t believe there is a way to consolidate this in a
> single UA processor because currently the application of the attributes is
> not deterministically ordered, so b may not be available when c is
> evaluated and applied. The current work around is to use linear dependent
> processors as you are doing. I do think this is a valid feature request
> that could be introduced in the UA processor without breaking backwards
> compatibility if you’re interested in filing the ticket. Changing the
> internal data structure of the dynamic properties to be ordered _should_ be
> possible, but I think currently the API doesn’t request that order so it
> would require a code change there, with a default practice being “order as
> received".
>
>
> Andy LoPresto
> alopresto@apache.org
> *alopresto.apache@gmail.com <al...@gmail.com>*
> He/Him
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> On Apr 22, 2020, at 12:04 PM, dan young <da...@gmail.com> wrote:
>
> Hello,
>
> I haven't been able to figure out if this is doable with a single
> UpdateAttrbute processor, but is it possible to create an attribute that
> references a different attribute you're setting in the same UpdateAttribute
> processor? ie.
>
> UpdateAttribute
> a = "foo"
> b = "bar"
> c = ${allAttributes("a", "b"):join(" _")}
>
> What I've been doing in the past is just have c in a downstream
> UpdateAttribute....wonder if there's a better way of doing this, or maybe
> in the Advance section of the UpdateAttribute.
>
>
> Regards,
>
> Dano
>
>
>
Re: UpdateAttribute processor question...
Posted by Andy LoPresto <al...@apache.org>.
Dan,
Unfortunately I don’t believe there is a way to consolidate this in a single UA processor because currently the application of the attributes is not deterministically ordered, so b may not be available when c is evaluated and applied. The current work around is to use linear dependent processors as you are doing. I do think this is a valid feature request that could be introduced in the UA processor without breaking backwards compatibility if you’re interested in filing the ticket. Changing the internal data structure of the dynamic properties to be ordered _should_ be possible, but I think currently the API doesn’t request that order so it would require a code change there, with a default practice being “order as received".
Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
He/Him
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Apr 22, 2020, at 12:04 PM, dan young <da...@gmail.com> wrote:
>
> Hello,
>
> I haven't been able to figure out if this is doable with a single UpdateAttrbute processor, but is it possible to create an attribute that references a different attribute you're setting in the same UpdateAttribute processor? ie.
>
> UpdateAttribute
> a = "foo"
> b = "bar"
> c = ${allAttributes("a", "b"):join(" _")}
>
> What I've been doing in the past is just have c in a downstream UpdateAttribute....wonder if there's a better way of doing this, or maybe in the Advance section of the UpdateAttribute.
>
>
> Regards,
>
> Dano
>