[
https://issues.apache.org/jira/browse/NIFI-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15715973#comment-15715973
]
ASF subversion and git services commented on NIFI-3140:
-------------------------------------------------------
Commit 316cae16d310f6131852e158f8ab274249f0ecc3 in nifi's branch
refs/heads/master from [~mattyb149]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=316cae1 ]
NIFI-3140: Restored optional type handling in FetchElasticsearchHttp
This closes #1288
Signed-off-by: jpercivall <[email protected]>
> FetchElasticsearchHttp no longer accepts optional type
> ------------------------------------------------------
>
> Key: NIFI-3140
> URL: https://issues.apache.org/jira/browse/NIFI-3140
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.1.0
> Reporter: Matt Burgess
> Assignee: Matt Burgess
> Fix For: 1.2.0
>
>
> In NiFi 1.1.0, if the Type property is omitted from the
> FetchElasticsearchHttp configuration (and a specific index is specified
> rather than _all), the processor fails with an error "400 Bad Request".
> This is a result of FetchElasticsearchHttp URL building being aligned with
> those used in the Query/ScrollElasticsearchHttp processors (added in
> NIFI-2417). Unfortunately the REST API is not consistent between the Get and
> Search APIs.
> For FetchElasticsearchHttp, the logic should be restored to insert a path
> segment of "_all" if the Type is not provided, and the Index property
> description should be reverted to not imply the use of "_all". Although it is
> possible to issue a successful Get against all indexes, it cannot have a type
> or document ID specified, and even then it does not return a document but
> instead a listing of indexes, which is inconsistent with the purpose of the
> processor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
