Elasticsearch 2.3 new API's feature parity #2017
Conversation
This commit adds support for the new 2.3 API's: * tasks_list * tasks_cancel * update_by_query * reindex The spec changes have also been updated in core upstream. The Reindex API is called `ReindexOnServer()` to offset it against our current `Reindex()` implementation which is still very useful. Both the reindex and update_by_query steal the status code from one of the failures and return a valid json body that we need to deserialize. To support this this AllowedStatusCodes now accepts a -1. .IsValid for these API's inspects whether any failures have been returned or not.
|
LGTM!
Maybe add a TODO to make this nullable instead in master?
👍 What are your thoughts for 5.0? I'm thinking we should rename ReindexOnServer to Reindex when we remove the old API. |
|
I quite like the idea of keeping both at least untill task result/state are stored in Elasticsearch somehow. Our roundtripping reindex might still be a lot easier to use and monitor through the non blocking RX observable we expose. Also remapping objects in C# is still alot easier then using scripts which might not even be enabled on the cluster. |
|
@Mpdreamz tasks cancel tests are failing in unit test mode. Looks like a setup issue - |
This commit adds support for the new 2.3 API's:
The spec changes have also been updated in core upstream.
The Reindex API is called
ReindexOnServer()to offset it against ourcurrent
Reindex()implementation which is still very useful.Both the reindex and update_by_query steal the status code from one of
the failures and return a valid json body that we need to deserialize.
To support this this AllowedStatusCodes now accepts a -1.
.IsValidfor these API's inspects whether any failures have beenreturned or not.