Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
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.
Attachments
Attachments
Issue Links
- links to
