calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Mior <>
Subject Re: Elasticsearch Adapter. Removal of Mapping Types (by vendor). Index == Table
Date Thu, 28 Jun 2018 21:23:22 GMT
Unfortunately I know very little about ES so I'm not in a great position to
asses the impact of these changes. I will say that that legacy
compatibility is great, but maintaining two sets of logic is always a
challenge. A few follow up questions:

1) What's the time horizon for the current adapter no longer working with
these changes to ES?

2) Any guess how complicated it would be to maintain code paths for both
behaviours? I know this is probably really challenging to estimate, but I
really have no idea of the scope of these changes. Would it mean two
different ES adapters?

3) Do we really need compatibility with the current version of the adapter?
IMO this depends on what versions of ES we would lose support for and how
complex it would be for users of the current ES adapter to make updates for
any Calcite API changes.

Thanks for your continued work on the ES adapter Andrei!

Michael Mior

Le jeu. 28 juin 2018 à 12:57, Andrei Sereda <> a écrit :

> Hello,
> Elastic announced
> <
> >
> that they will be deprecating mapping types in ES6 and indexes will be
> single-typed only.
> Historical analogy <> between
> RDBMS and elastic was that index is equivalent to a database and type
> corresponds to table in that database. In a couple of releases (ES6-8) this
> shall not longer be true.
> Recent SQL addition
> <> to elastic
> confirms
> this trend
> <
> >.
> Index is equivalent to a table and there are no more ES types.
> I would like to propose to include this logic in Calcite ES adapter. IE,
> expose each ES single-typed index as a separate table inside calcite
> schema. This is in contrast to  current integration where schema can only
> have a single index. Current approach forces you to create multiple schemas
> to query single-typed indexes (on the same ES cluster).
> Legacy compatibility can always be controlled with configuration
> parameters.
> Do you agree with such changes ? If yes, would you consider a PR ?
> Regards,
> Andrei.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message