I have simplistic entity with property named "Id" of type String in my C# code.
I also have an index with a number of documents uploaded via Bulk API. Document's schema doesn't include "id" field. The only thing that I have is a standard Elasticsearch's "_id" property.
So when it gets to retrieving documents (var response = _esClient.Search<Poco>(s => s.MatchAll())), I clearly see that Id has correct value in every object in response's Hits array property.
However, when I do var documents = response.Documents.ToList(), all my documents has Id = null.
What I've tried is setting IdProperty in ConnectionSettings - still no luck. So I don't really see a way to map Elasticsearch's "_id" to my entity's Id property.
Description of the problem including expected versus actual behavior:
NEST/Elasticsearch.Net version: latest
Elasticsearch version: latest
Steps to reproduce:
var documents = _esClient.Search<Poco>(s => s.MatchAll()).Documents.ToList()ER: documents is a list of Pocos where each object has Id property equal to corresponding document's "_id" field in Elasticsearch.
AR: Id = null in all objects.
ConnectionSettings:
_settings =
new ConnectionSettings(_node)
.DefaultIndex("pocos")
.DefaultTypeName("doc")
.DefaultMappingFor<Poco>(
m => m
.IndexName("pocos")
.TypeName("doc")
.IdProperty(p => p.Id)); // this one doesn't work anyway
_esClient = new ElasticClient(_settings);
@maxsel It's intentional behaviour and by design to not map the _id in the hit metadata returned for a hit to an Id property on a POCO during deserialization. It's been discussed quite a few times before, the most recent is https://github.com/elastic/elasticsearch-net/issues/1293. It can be mapped with
```c#
var response = client.Search
var pocoListWithIds = response.Hits.Select(h =>
{
h.Source.Id = h.Id;
return h.Source;
}).ToList();
```
Thoughts on revisiting this @Mpdreamz and @codebrain ? I have some thoughts about Elasticsearch autogenerated Ids that could tie in with this i.e. exposing the ability to configure on ConnectionSettings to
_id hit metadata to the POCO (on responses where this data is available).Thanks for explanation @russcam, duplicating document's hit metadata "_id" in the source as document's "id" field worked for us. Though it's an obvious duplication, the code looks much better without that explicit mapping :)
I'm new to Nest and ElasticSearch but one vote for remove the one way mapping OR make it 2 way.
Thanks! B-)
We discussed this again recently and voted to close this issue based on the following:
DefaultDisableIdInference_source and set it to not indexed in the mapping.Hits into your POCO as shown here: https://github.com/elastic/elasticsearch-net/issues/3350#issuecomment-410618969So for now we shall close, unless there is a compelling reason to re-open.
@codebrain I thought I noticed this behavior in a recent version of NEST. I remember having an Id field set automatically somehow, but it's possible that I handled this with AutoMapper and forgot about it.
Is there an equivalent for the Version property to automatically retrieve and store the version information without additional mapping?
Most helpful comment
@maxsel It's intentional behaviour and by design to not map the
_idin the hit metadata returned for a hit to an Id property on a POCO during deserialization. It's been discussed quite a few times before, the most recent is https://github.com/elastic/elasticsearch-net/issues/1293. It can be mapped with```c#(searchDescriptor);
var response = client.Search
var pocoListWithIds = response.Hits.Select(h =>
{
h.Source.Id = h.Id;
return h.Source;
}).ToList();
```
Thoughts on revisiting this @Mpdreamz and @codebrain ? I have some thoughts about Elasticsearch autogenerated Ids that could tie in with this i.e. exposing the ability to configure on
ConnectionSettingsto_idhit metadata to the POCO (on responses where this data is available).