Sonke, The main ElasticSearch bundle should easily support ElasticSearch in most cases through v6. The only question at this point will be updating it to support the removal of types around the release of v7.
The new REST API NAR bundle that provides JsonQueryElasticSearch is built on client services that use the official API. I'm working that, but there's no official timeline on when it will be a full CRUD replacement for the others. I would recommend avoiding the "v5 bundle" because it uses the transport protocol, and around Elastic v7 that will become a private API in favor of a pure REST approach. Thanks, Mike On Fri, Feb 8, 2019 at 4:58 AM Sönke Liebau <soenke.lie...@opencore.com.invalid> wrote: > Hi, > > I've just spent a little time looking over the existing Elasticsearch > processors and digging through the jira for a little history around > what happened so far, and I have a few points that I am unclear on. > Maybe someone can clarify this for me? > > Are there any plans to change the PutElasticsearch processor to use > the official High-(or Low-) Level Rest client instead of building the > Rest requests "manually"? > > Is there a versioning strategy going forward? I think we can probably > expect Elasticsearch breaking compatibility every now and then, > especially with major versions. Will there be a new PutElasticsearch7 > processor for the next major version in case that happens? > Would it be an alternative to handle this internally, query the > version we are running against and then have different versions of the > library shaded / build different requests as necessary? > > Not proposing anything here, just trying to get up to speed :) > > Best regards, > Sönke >
