Should mention that I did not check the L&N for the ES 6.X version. That needs to be reviewed as part of the PR.
On Mon, Jun 11, 2018 at 7:54 AM Mike Thomsen <mikerthom...@gmail.com> wrote: > https://github.com/apache/nifi/pull/2782 > > Renamed the service and added a clone for 6.X. The integration tests use a > Maven ES plugin that downloads ES, bootstraps it with test data and runs > the integration tests against that. The 6.X version uses the latest stable > build (6.2.4) and passed all integration tests. > > On Sun, Jun 10, 2018 at 11:35 AM Mark Payne <marka...@hotmail.com> wrote: > >> I think it’s a good idea to go ahead and rename it. Even if 6.x doesn’t >> make breaking changes, 7.x may. And I’d rather not have an >> ElasticSearchClient that works for 5.x and 6.x and then an >> ElasticSearchClient_7 that deals with 7. It makes it look like the simply >> named ElasticSearchClient is generic and will work with any version. This >> is what we did with the PublishKafka* processors and it has only caused >> confusion. >> >> Sent from my iPhone >> >> > On Jun 10, 2018, at 8:20 AM, Mike Thomsen <mikerthom...@gmail.com> >> wrote: >> > >> > I think types are required in 5.X and optional in 6.X. By 8.X types are >> > going to be firmly eliminated, so that's at least one area of research >> that >> > needs to be done I suppose. >> > >> > On Sun, Jun 10, 2018 at 7:53 AM Sivaprasanna <sivaprasanna...@gmail.com >> > >> > wrote: >> > >> >> I feel if the upgrade from 5.x to 6.x client doesn't introduce any >> breaking >> >> changes, we can continue with the name that we are having now. >> >> >> >> - >> >> Sivaprasanna >> >> >> >> On Sun, Jun 10, 2018 at 5:16 PM, Mike Thomsen <mikerthom...@gmail.com> >> >> wrote: >> >> >> >>> The current implementation uses the last stable release of the 5.X >> client >> >>> from Elastic, and 6.X is already mature so we'll need to be able to >> have >> >>> room to create a new implementation copy that uses that client if >> there >> >> are >> >>> things we have to change between them. So does it make sense to throw >> in >> >> a >> >>> new ticket to rename the service to something that indicates that this >> >>> implementation is officially for 5.X? As of 1.6 I think only one >> >> processor, >> >>> JsonQueryElasticSearch, uses it so not many uses would likely be >> impacted >> >>> yet. >> >>> >> >>> Thanks, >> >>> >> >>> Mike >> >>> >> >> >> >