[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ElasticSearch adapter. Exposing meta fields (like _id, _uid etc.)

Hi Andrei,

Many data management systems have internal columns which the users may be
able to query (see for example Postgres [1]). It doesn't sound unnatural to
allow users access these fields. On the other hand such system columns do
not appear in SELECT * queries and I suppose they are pruned out by
projections early on if they are not used by the query. I guess you could
take a similar approach in the ElasticSearch adapter.


[1] https://www.postgresql.org/docs/current/ddl-system-columns.html

Στις Σάβ, 22 Δεκ 2018 στις 1:14 π.μ., ο/η Andrei Sereda <andrei@xxxxxxxxx>

> Hello,
> Upon indexing, elastic allocates a unique _id
> <
> https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-id-field.html
> >
> for each document (unless specified by the user). Currently when mapping
> between elastic result and calcite return type we query only _source or
> fields attributes. _id is not part those but exposed at higher level in
> query response (see SearchHit
> <
> https://www.elastic.co/guide/en/elasticsearch/reference/6.1/_the_search_api.html
> >
> ).
> Currently  _MAP['foo'] becomes _source.get('foo') (or fields.get('foo')).
> Do you think we should make _MAP['_id'] available implicitly ?
> I have a couple of use-cases where one needs to know document ID.
> Please note this makes sense only for non-aggregate queries.
> Regards,
> Andrei.