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
>> >>>
>> >>
>>
>

Reply via email to