spring-data-elasticsearch icon indicating copy to clipboard operation
spring-data-elasticsearch copied to clipboard

On deleting data with ElasticSearchrestTemplate delete or doDelete method

Open zhushuaiCoding opened this issue 3 years ago • 1 comments

Regarding the ElasticSearchrestTemplate delete or doDelete method to delete data, if there is no data, then ID is also returned, which should be a bug. If there is no data, ID should not be returned, so it is not known whether the data has been deleted. Can you provide a method to return the deleteresponse object and let the developer judge it by himself. Solution: protected DeleteResponse doDeleteResponse(String id, @Nullable String routing, IndexCoordinates index) { Assert.notNull(id, "id must not be null"); Assert.notNull(index, "index must not be null"); DeleteRequest request = prepareWriteRequest( requestFactory.deleteRequest(elasticsearchConverter.convertId(id), routing, index)); return execute(client -> client.delete(request, RequestOptions.DEFAULT)); }

zhushuaiCoding avatar May 31 '21 08:05 zhushuaiCoding

Not returning an ID when there is no data would break the existing API.

so it is not known whether the data has been deleted.

No. When the call returns, there is no entity with this id in the index anymore. Otherwise some error would have occured which had prevented the deletion and that would have been returned by Elasticsearch as an error. If you need to know if the entity existed before deleting you'd need an exists(id) call.

As for exposing the internal Elasticsearch data structures in our API: We don't do that, although there are places where this is still done, basically from old code. The main reason for this is that this tightly couples the user's code to the Elasticsearch classes, and changes in Elasticsearch will then break the user's code. That's exactly what Spring Data Elasticsearch tries to prevent by encapsulating away the Elasticsearch API.

We know that we need should provide some kind of integration hook where client code can plug into the process of sending requests and processing responses, but this should then use the same approach for the imperative and the reactive rest clients - and the whole client architecture will change in a not so far future.

After the license change of Elasticsearch with version 7.12. they are aware that the RestHighLevelClient depends on code in the Elasticsearch core libraries; they are now working on a new Elasticsearch client library which will be released under an Apache2 license, but this new library (that will replace the RestHighLevelClient) is a completely new written implementation. When this new implementation is available, we will need to change our implementations of ElasticsearchRestTemplate and ReactiveElasticsearchTemplate to use the new client, request and response converters that this new client will provide. With this change we can integrate some hooks.

So there won't be any changes in this direction before the new client is released by Elasticsearch.

sothawo avatar May 31 '21 16:05 sothawo

Both ElasticsearchTemplate and ReactiveElasticsearchTemplate provide a method execute() that takes a callback method that gets passed the underlying client to operate on. By this it is possible to do any call directly on the client and inspect/process the returned result.

sothawo avatar Nov 19 '22 14:11 sothawo