[ 
https://issues.apache.org/jira/browse/NIFI-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510538#comment-16510538
 ] 

ASF GitHub Bot commented on NIFI-5287:
--------------------------------------

Github user ijokarumawak commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/2777#discussion_r194933023
  
    --- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestLookupRecord.java
 ---
    @@ -400,6 +433,20 @@ public void addValue(final String key, final String 
value) {
             public Set<String> getRequiredKeys() {
                 return Collections.singleton("lookup");
             }
    +
    +        public void setRequiredCoordinates(Map<String, Object> 
expectedCoordinates) {
    +            this.expectedCoordinates = expectedCoordinates;
    +        }
    +
    +        private void enforceRequiredCoordinates(Map<String, String> 
context) {
    --- End diff --
    
    This should be renamed to `validateContext`. And every name using 
`coordinates` should be replaced with `context`.


> 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)

Reply via email to