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