Id property inference

Referring to this page: http://nest.azurewebsites.net/nest/index-type-inference.html

You can control which propery holds the Id:

[ElasticType(IdProperty="CrazyGuid")]
public class Car 
{
    public Guid CrazyGuidId { get; set; }
}

This will cause the the id inferring to happen on CrazyGuid instead of Id.

Is the mismatch deliberate or is this just a typo: should the attribute refer to CrazyGuidId, or should the property name be CrazyGuid? There are other typos on the page so it’s hard to tell ¯_(ツ)_/¯

I am having trouble getting the ID from items in ES using this method, using v1.4.2

---

EDIT: I came across this line on the same page:

Whenever an object is passed that needs to specify an id (i.e index, bulk operations) the object is inspected to see if it has an Id property and if so, that value will be used.

So the ID property only inferred from the type when using a .Id() search descriptor? If so, what’s the recommended way of getting the _id property for documents from the Search<T> api?

[russcam]

Upon further discussion on this issue, we’ve decided to keep the current implementation for the time being. We feel it would be potentially confusing if the Id property on the Poco were populated with data that is not contained within the _source field in Elasticsearch; A Poco instance is a representation of the source document.

I’ll add documentation for NEST 2.x demonstrating how to retrieve the _id from the metadata using the .Hits property on the response and set a property on the Source as demonstrated above.

[rikkit]

The uid property doesn’t exist in my mapping, imo it shouldn’t because it is already part of the document metadata. To reiterate my point, I expected this feature to be a “transparent” way to get the ID of a document without having to have an id field stored in the document metadata.

As it stands, this feature is not useful for me, exactly because the read case differs from the write case.

If I put this document into ES using this mechanism:

[ElasticType(IdProperty="Uid")]
class Poco {
    [JsonIgnore] // alternatively to this attribute mapping could be explicit and dynamic mapping disabled
    public string Uid {get;set;}
    public string Prop {get;set;}
}

_nest.Index<Poco>(x => x.Index(i).Type(t).Document(new Poco{ Uid = "banana", Prop = "apple" });

And then I retrieved it again:

var poco2 = _nest.Get<Poco>(x => x.Index(i).Type(t).Id("banana");

I would not have the same object (poco1.Uid == banana, poco2.Uid == null).

What use cases does the current behaviour serve? It’s not what I expected based on the documentation. And like @irfansharif says the workaround I posted is not easily testable.