[jira] [Updated] (NIFI-5287) LookupRecord should supply flowfile attributes to the lookup service

["Mike Thomsen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NIFI-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Thomsen updated NIFI-5287:
-------------------------------
    Description: 
-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.

  was:
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.


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