LookupAttribute + CSV Lookup handling of non-matches

[Andre <an...@fucs.org>]

Hi all,

I have been playing with the lookup attribute and noticed a behavior that
seems counter intuitive to me:

When using the SimpleCSVLookupService I noticed that whenever the service
fails to find a match to a particular value, the LookupAttribute processor
still populated the respective dynamic property with "null" and routed the
flowfile to match instead of leaving the field untouched and transferring
the flow to unmatched.

Is this expected behavior? If so, what is the use of unmatched?

Kind regards

Re: LookupAttribute + CSV Lookup handling of non-matches

[Joe Witt <jo...@gmail.com>]

sounds similar to https://issues.apache.org/jira/browse/NIFI-4103

On Thu, Jun 22, 2017 at 12:36 AM, Andre <an...@fucs.org> wrote:
> Hi all,
>
> I have been playing with the lookup attribute and noticed a behavior that
> seems counter intuitive to me:
>
> When using the SimpleCSVLookupService I noticed that whenever the service
> fails to find a match to a particular value, the LookupAttribute processor
> still populated the respective dynamic property with "null" and routed the
> flowfile to match instead of leaving the field untouched and transferring
> the flow to unmatched.
>
> Is this expected behavior? If so, what is the use of unmatched?
>
> Kind regards

Re: LookupAttribute + CSV Lookup handling of non-matches

[Andre <an...@fucs.org>]

Joey,

Thanks for the reply.

Yeah, I probably would get to that property soon or later but I reckon the
property description should be revisited. I think we should make it quite
explicit that setting this to true will result in unmatched to stop working
as expected.

On Thu, Jun 22, 2017 at 2:43 PM, Joey Frazee <jo...@icloud.com> wrote:

> Andre, there's a flag for "Include Empty Values". If set to false then the
> effect is that non-matches result in a transfer to unmatched. The default
> is true so I'd expect to see what you're seeing.
>
> The description for that property isn't good enough though. I don't know
> how you would have known this now that I'm looking at the docs again.
>
> -joey
>
> > On Jun 21, 2017, at 11:36 PM, Andre <an...@fucs.org> wrote:
> >
> > Hi all,
> >
> > I have been playing with the lookup attribute and noticed a behavior that
> > seems counter intuitive to me:
> >
> > When using the SimpleCSVLookupService I noticed that whenever the service
> > fails to find a match to a particular value, the LookupAttribute
> processor
> > still populated the respective dynamic property with "null" and routed
> the
> > flowfile to match instead of leaving the field untouched and transferring
> > the flow to unmatched.
> >
> > Is this expected behavior? If so, what is the use of unmatched?
> >
> > Kind regards
>

Re: LookupAttribute + CSV Lookup handling of non-matches

[Joey Frazee <jo...@icloud.com>]

Andre, there's a flag for "Include Empty Values". If set to false then the effect is that non-matches result in a transfer to unmatched. The default is true so I'd expect to see what you're seeing.

The description for that property isn't good enough though. I don't know how you would have known this now that I'm looking at the docs again.

-joey

> On Jun 21, 2017, at 11:36 PM, Andre <an...@fucs.org> wrote:
> 
> Hi all,
> 
> I have been playing with the lookup attribute and noticed a behavior that
> seems counter intuitive to me:
> 
> When using the SimpleCSVLookupService I noticed that whenever the service
> fails to find a match to a particular value, the LookupAttribute processor
> still populated the respective dynamic property with "null" and routed the
> flowfile to match instead of leaving the field untouched and transferring
> the flow to unmatched.
> 
> Is this expected behavior? If so, what is the use of unmatched?
> 
> Kind regards