[ https://issues.apache.org/jira/browse/NIFI-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16511825#comment-16511825 ]
ASF GitHub Bot commented on NIFI-5287: -------------------------------------- Github user MikeThomsen commented on a diff in the pull request: https://github.com/apache/nifi/pull/2777#discussion_r195270966 --- 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 -- Done. > 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)