How can I create a simple match query?

Going on with my tests I wanted to create a simple match query for a call like this:

GET /test-index/_search
{
  "query": {
    "match": {
      "message": {
        "query": "this is a test"
      }
    }
  }
}

I try to use this code:

		SearchRequest searchRequest = new SearchRequest.Builder()
				.index("test-index")
				.query(b -> b
						.match(
								// what to use here????
						))
				.build();

The QueryContainer.Builder has these 2 match methods:

        public ObjectBuilder<QueryContainer> match(NamedQuery<JsonValue> v) {
            this.$variant = v;
            this.$tag = QueryContainer.Tag.match;
            return new Constant(this.build());
        }

        public ObjectBuilder<QueryContainer> match(Function<co.elastic.clients.elasticsearch._types.query_dsl.NamedQuery.Builder<JsonValue>, ObjectBuilder<NamedQuery<JsonValue>>> f) {
            return this.match((NamedQuery)((ObjectBuilder)f.apply(new co.elastic.clients.elasticsearch._types.query_dsl.NamedQuery.Builder())).build());
        }

what would I need to put there? I am missing a MatchQuery class here. Or something like

.match(m -> m.field("message").query("this is a test").build()

The same problem comes up when trying to build a simple terms query.

[sothawo]

Having some reactive client would be nice; currently I have an implementation where I add reactive versions of the imperative part (if you have spare time you can look at what I did here: https://github.com/sothawo/spring-data-elasticsearch/tree/new-Elasticsearch-client/src/main/java/org/springframework/data/elasticsearch/clients/reactive/elasticsearch - still work in progress as well).

The problem is that I have to make sure that all the methods that exist in the imperative part are adapted to the reactive part. Having some base class or interface would help.

But I think that is not necessarily needed for the first version, it’s more important to have all the requests and responses available.

btw, the RestClient implements Closeable and should be closed when not used anymore. Would it make sense to make ElasticsearchClient implement AutoCloseable and pass a call to close() down to the RestClient?

[sothawo]

I didn’t want to rush you, it just might have been that some part of the autogeneration was not executed properly although it should. So there’s no problem with that, there are still enough parts I can work on. Btw, great work, I like that concept with the Transport and the Endpoint that helps a lot in building a reactive Elasticsearch Client that can reuse the code to build requests and parse responses.

When this will be released we can have a great cleanup of code in Spring Data Elasticsearch, looking forward to it.

I’ll close this issue and patiently wait for the next releases.