Refactoring accessors using only getters and setters

[dadoonet]

We want to clean up the code and use only standard accessors (gettters and setters).
So we remove old non standard accessors.

Current request builders to build request with elasticsearch stay the same, and its the recommended way to execute APIs with elasticsearch. The pure "request" APIs have changed, and now have setters methods instead of the non setters options, code will need to change if pure Request objects/api are used.

Last, all response levels objects now only expose the getter API variant. We have had both variants (getter and non getter) for some time, and its time to clean it up as it creates both confusion and overhead on our end to maintain it.

[michaelklishin]

Please reconsider this change. It breaks a lot of examples in the docs, on the mailing list and all over the Internet. Leave alone a lot of apps that use the transport client.

[kimchy]

@michaelklishin the assumption is that people have moved to use the RequestBuilders on the client side, and nothing breaks there on the request side. Regarding the response, maintaining the non getter options is just an overhead on our end, we have the getter option for a long time now, hopefully people have migrated to it so there won't be a problem.

[kimchy]

@michaelklishin thinking about ti a bit more, I think we took teh change a bit too far with changing the XXXRequest methods. We will revert changing those, but still keep the removal of Response xxx methods and just stay with getXXX methods.

[jprante]

This breaks a lot of method API calls I have use in plugins, just because I assumed the other way round is preferred (getters/setters are from the old JavaBeans model, in contrast to fluent interface style). I would have loved to see @deprecated markers before. Please, reconsider this change in favor to announce such large changes in the API carefully, with deprecated method markers, so we have time to rewrite the code.

[michaelklishin]

There's plenty of information on the Web that constructs requests directly, and this is what I've been doing with
the native client in Elastisch. I will switch to request builder but it still sounds
like a good idea to deprecate + keep the current API methods for a release or two (say, remove them after 0.22).

Thank you for taking the time!

[kimchy]

Actually, the main goal of the change was remove the duplication on the getXXX nad xxx methods on the Response side. We probably took it a step too far with changing the request methods as well, there are benefits (also on teh groovy client) to use non settter methods.

[derryos]

Hi there,

I have logged an issue on this in the forum:
https://groups.google.com/d/msg/elasticsearch/O3uzXQtyrKE/5kysBggsft8J

For many of these accessors that changed, the old version still exists (for deprecation, i guess?) e.g.:
GetResponse
exists() -> isExists()
CountResponse
count() -> getCount()
SearchResponse
hits() -> getHits()
ClusterHealthResponse
status() -> getStatus()

This means that i could easily go back to v0.20.4 from 0.90.0.Beta1 once i update my code to use the alternative accessor.

One, however, that i don't see is:
BuldResponse
items() vs getItems()

This means that i can't easily switch between versions without code changes.

Is there are reason why some of the accessors have changed and not others?

[dadoonet]

I added the following comment in the forum:

I can't see old versions in repo:
https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/get/GetResponse.java#L56
https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/count/CountResponse.java#L51
https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/search/SearchResponse.java#L91
https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/admin/cluster/health/ClusterHealthResponse.java#L119

https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/bulk/BulkResponse.java#L92

Where do you see old getters?

[derryos]

After conversations with david above, it seems that this was down to me not having a clean maven project. The issue occured because i seemed to have co-existing es libraries (ie was switching my pom between versions, forcing a project clean and only issue i had was in the bulkResponse items() vs getItems call). Restarting eclipse and forcing a clean maven update means that i now only see the correct accessors.

[randunel]

So we should use ES 0.20 until all the plugins/rivers have been updated, right? Could someone please post an official download link for the latest version until this change? Is this the one? http://www.elasticsearch.org/downloads/0-20-6/

[derryos]

Just a comment on this - the java api doc (specifically using scrolls) on the elasticsearch site mixes hits() and getHits().
http://www.elasticsearch.org/guide/en/elasticsearch/client/java-api/current/search.html

for (SearchHit hit : scrollResp.getHits()) {
//Handle the hit...
}
//Break condition: No hits are returned
if (scrollResp.*_hits()_.hits().length == 0) { //ES 0.90+ complains!
break;
}

[spinscale]

Hey, thanks a lot for bringing this up! I just changed it in the documentation. Dont hesitate to create a new issue for outdated or wrong documentation!