Remove search-exists API

[clintongormley]

The search-exists API tells you if there are any matching results, without performing a count. Besides this being an almost-never-useful operation, it could easily be replicated with:

GET _search?size=0&terminate_after=1

I propose removing this API.

[nik9000]

I propose removing this API.

I'm certainly fine with it. I've never used it in production.

[javanna]

+1

[bleskes]

Will we also wire HEAD _search to do the same and add terminate_after?

On 22 Sep 2015, at 10:10, Luca Cavanna [email protected] wrote:

+1

—
Reply to this email directly or view it on GitHub.

[clintongormley]

@bleskes no - some clients don't support HEAD with body. I don't see the need for sugar here

[bleskes]

I don’t follow the logic? if you do submit a head a request, why not make sure return as fast as possible with the information needed (this is something there).

On 22 Sep 2015, at 15:21, Clinton Gormley [email protected] wrote:

@bleskes no - some clients don't support HEAD with body. I don't see the need for sugar here

—
Reply to this email directly or view it on GitHub.

[honzakral]

Also do we add/leave this functionality in the client as a shortcut? There is a precedent to it with the create API that is just index with op_type=create.

[clintongormley]

@bleskes first, i have never heard of anybody using this feature, and can't come up with a real use case for it anyway. Second, not all clients can support it. Third, it is easy to replicate the functionality by just setting ?size=0&terminate_after=1

@honzakral I would say we don't bother supporting it in the client as the feature is really not useful.

[bleskes]

first, i have never heard of anybody using this feature, and can't come up with a real use case for it anyway.

I was asked about it a while ago. Not sure if the use case at the time. The one I can think of out of the top of my had is wanting to validate that a search link will actually lead to results - for example a "did you mean" recommendation link (which may come from the completion suggester or another system).

Second, not all clients can support it

Those that do can, and those don't can't. Just like GET with a body imho. As you say, it's not in your way if you can't.

All I wanted is to make sure this gets some attention. It's super easy to implement on the ES side (and we don't now) and to me is what I would expect from a HEAD _search request. If you rather not do but wait for an, eventual, feature request - it's good with me.

[clintongormley]

Another good reason for removing search-exists: #13094

[javanna]

I am looking into this. I think we may want to make terminate_after non experimental before using it as a replacement for apis that we are removing. Any reasons why terminate_after is still experimental in our docs?

[jpountz]

I think it has been made experimental because it was initially used by suggesters. But then we deprecated the limit filter in favour of it and now we are thinking of doing the same for the search/exists API, so it probably makes sense to remove the experimental flag.

[honzakral]

@clintongormley do you have any data why you are saying it's not useful? People are using it and asking questions around it. Due to it's inconsistencies (#11204) more than about any other API.

[clintongormley]

@honzakral i don't have data, just instinct (which may well be wrong). However, this is a really simple function that can be entirely replaced by the search API, which is much more thoroughly tested (and much more widely used). My goal here is to reduce the surface area of these APIs to make the code base easier to maintain and test.

You're free to add a convenience method to the python API if you feel strongly about it.