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.
Best, Stamatis [1] https://www.postgresql.org/docs/current/ddl-system-columns.html Στις Σάβ, 22 Δεκ 2018 στις 1:14 π.μ., ο/η Andrei Sereda <[email protected]> έγραψε: > 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. >
