Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Allow native access to the Elasticsearch RestClient

Description

Sometimes it is necessary to send a request to Elasticsearch for something that simply does not exist in Hibernate Search. Let's say an administration command, for example.

Currently, the only option for users is to create their own client and use that. They cannot use our client.

If we want to change that, we have three options:

  1. Expose our internal client, something like ElasticsearchBackend.getClient() returnin a org.elasticsearch.client.RestClient.

  2. Promote our own abstraction layer (org.hibernate.search.v6poc.backend.elasticsearch.client.impl.ElasticsearchClient, org.hibernate.search.v6poc.backend.elasticsearch.client.impl.ElasticsearchRequest, org.hibernate.search.v6poc.backend.elasticsearch.client.impl.ElasticsearchResponse, GSON, ...) to API and expose that.

  3. Create an additional abstraction layer on top of our own and expose that.

I would much rather do 3., so that we are not stuck with the current technologies (Apache HTTP Client + GSON) forever just because they are exposed through our APIs. Especially since we already considered switching from GSON to something else (HSEARCH-2817, HSEARCH-2835) and from the Apache HTTP Client to something else.

Note the "additional abstraction layer" could be very thin and very simple: it would be very close to our own abstraction layer, it would only be a matter of requring the body elements to be passed as strings instead of GSON's JsonObjet.

Activity

Sanne GrinoveroApril 19, 2018 at 4:08 PM

Sanne GrinoveroApril 18, 2018 at 9:29 AM
Edited

We could wrap the client with our own facade but that has two drawbacks:

  • it implies it's an API / SPI which means we endorse its usage

  • we would need to track the ElasticSearch API closely to make sure we expose any new things they might add

So I prefer proposal 1. : allow to grab a reference to "our" org.elasticsearch.client.RestClient, yet not introducing an ad-hoc method to accomplish this.

There are two options to do that:

  1. either we explain how to use the ServiceRegistry to grab a ElasticsearchClientFactory - not ideal as you'd still need to initialize a new client instance, not to mention using the services is a bit verbose.

  2. enhance SearchFactory#unwrap - a bit tricky to implement but should be doable

My preference is the unwrap() method.

Drawbacks: I would not attempt to decorate/protect/enhance the returned client, which means people could in theory close it, change the hosts, or do other nasty things but IMO that's the level of control they are asking for.

Ideally we could ask the Elasticsearch team to introduce a safe facade for such use cases but such a contract belongs in the Elasticsearch client project.

Guillaume SmetApril 18, 2018 at 8:11 AM

I suspect users will want to have access to the high level Elasticsearch client instead of the low level one.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Priority

Created April 18, 2018 at 6:45 AM
Updated May 4, 2018 at 1:18 PM
Resolved April 26, 2018 at 1:59 PM