ASF GitHub Bot commented on NIFI-3140:

Github user mattyb149 commented on the issue:

    @gresockj Do you mind taking a look at this? I want to make sure I didn't 
miss something in the API or any potential differences between versions. For 
the Http processors I'd like to keep the least-common-denominator principle, 
since they are the alternative to the other Transport-based processors that 
require a particular (major) version.  Thanks!

> 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

Reply via email to