[
https://issues.apache.org/jira/browse/NIFI-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509699#comment-16509699
]
ASF GitHub Bot commented on NIFI-5287:
--------------------------------------
Github user ijokarumawak commented on the issue:
https://github.com/apache/nifi/pull/2777
As for Variable Registry, I think passing only FlowFile attribute is
enough, same as the way AbstractRecordProcessor is doing right now.
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/AbstractRecordProcessor.java#L113
In that sense, I found a contradiction between current documentation and
behavior. Schema Name, Schema Version, Schema Branch and Schema Text are
documented that those supports Variable Registry and FlowFile Attributes, but
it can only access to FlowFile attributes. I assume this pattern is not
considered when ExpressionLanguageScope is added. Probably for another JIRA
(not filed yet).
> LookupRecord should supply flowfile attributes to the lookup service
> --------------------------------------------------------------------
>
> Key: NIFI-5287
> URL: https://issues.apache.org/jira/browse/NIFI-5287
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Mike Thomsen
> Assignee: Mike Thomsen
> Priority: Major
>
> -LookupRecord should supply the flowfile attributes to the lookup service. It
> should be done as follows:-
> # -Provide a regular expression to choose which attributes are used.-
> # -The chosen attributes should be foundation of the coordinates map used
> for the lookup.-
> # -If a configured key collides with a flowfile attribute, it should
> override the flowfile attribute in the coordinate map.-
> Mark had the right idea:
>
> I would propose an alternative approach, which would be to add a new method
> to the interface that has a default implementation:
> {{default Optional<T> lookup(Map<String, Object> coordinates, Map<String,
> String> context) throws LookupFailureException \{ return lookup(coordinates);
> } }}
> Where {{context}} is used for the FlowFile attributes (I'm referring to it as
> {{context}} instead of {{attributes}} because there may well be a case where
> we want to provide some other value that is not specifically a FlowFile
> attribute). Here is why I am suggesting this:
> * It provides a clean interface that properly separates the data's
> coordinates from FlowFile attributes.
> * It prevents any collisions between FlowFile attribute names and
> coordinates.
> * It maintains backward compatibility, and we know that it won't change the
> behavior of existing services or processors/components using those services -
> even those that may have been implemented by others outside of the Apache
> realm.
> * If attributes are passed in by a Processor, those attributes will be
> ignored anyway unless the Controller Service is specifically updated to make
> use of those attributes, such as via Expression Language. In such a case, the
> Controller Service can simply be updated at that time to make use of the new
> method instead of the existing method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
