[
https://issues.apache.org/jira/browse/NIFI-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419524#comment-16419524
]
Joseph Percivall commented on NIFI-3576:
----------------------------------------
So to summarize we have a couple of different options:
# A new 'original' relationship to route the original FlowFile which has an
attribute like 'es.hits.total' - precedent set by InvokeHttp
# A 'none found' relationship which routes a FlowFile when there are no hits -
precedent set by FetchElasticsearch(5)
# Emit a FlowFile to "Success" for but add an attribute 'es.hits.total' -
matches the 'Success' relationship documentation which states "All FlowFiles
that are read from Elasticsearch are routed to this relationship."
I'm leaning more towards option 3. It seems more in line with the original
intent of the relationship, and the processor as a whole. It's querying for
potential hits, not fetching a single document, so having no results but, a
successful query is valid. Also, this means that users won't have an invalid
processor on migration (the new relationships wouldn't be routed anywhere).
Then we also aren't duplicating logic which could just be in a follow-up
RouteOnAttribute processor.
Thoughts?
> QueryElasticsearchHttp should have a "Not Found"/"Zero results" relationship
> ----------------------------------------------------------------------------
>
> Key: NIFI-3576
> URL: https://issues.apache.org/jira/browse/NIFI-3576
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Joseph Percivall
> Assignee: Otto Fowler
> Priority: Minor
>
> In the event of a successful call, QueryElasticsearchHttp always drops the
> incoming flowfile and then emits pages of results to the success
> relationship. If the search returns no results then no pages of results are
> emitted to the success relationship.
> The processor should offer other options for handling when there are no
> results returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
