I suppose the downside in an HTTP ES sink is that you don't get _any_
form of high-level API from ES, and we'd have to manually build an HTTP
request that matches the ES format. Of course you also lose any
client-side verification that the clients did, if there is any (but I
guess the API itself prevented certain errors).
On 11/02/2020 09:32, Stephan Ewen wrote:
+1 to drop ES 2.x - unsure about 5.x (makes sense to get more user input
for that one).
@Itamar - if you would be interested in contributing a "universal" or
"cross version" ES connector, that could be very interesting. Do you know
if there are known performance issues or feature restrictions with that
approach?
@dawid what do you think about that?
On Tue, Feb 11, 2020 at 6:28 AM Danny Chan <yuzhao....@gmail.com> wrote:
5.x seems to have a lot of users, is the 6.x completely compatible with
5.x ~
Best,
Danny Chan
在 2020年2月10日 +0800 PM9:45，Dawid Wysakowicz <dwysakow...@apache.org>，写道：
Hi all,
As described in this https://issues.apache.org/jira/browse/FLINK-11720
ticket our elasticsearch 5.x connector does not work out of the box on
some systems and requires a version bump. This also happens for our e2e.
We cannot bump the version in es 5.x connector, because 5.x connector
shares a common class with 2.x that uses an API that was replaced in 5.2.
Both versions are already long eol: https://www.elastic.co/support/eol
I suggest to drop both connectors 5.x and 2.x. If it is too much to drop
both of them, I would strongly suggest dropping at least 2.x connector
and update the 5.x line to a working es client module.
What do you think? Should we drop both versions? Drop only the 2.x
connector? Or keep them both?
Best,
Dawid
