.Automap() unexpected behaviour with overridden properties

[anellomancante]

NEST/Elasticsearch.Net version: 5.0.1

Elasticsearch version: 5.1.2

Description of the problem including expected versus actual behavior:

NEST Automap implementation returns unexpected mappings when scanning types with overridden properties.
If I have the following class hierarchy:

public class TestClass
{
	public Guid Property1 { get; set; }
	public Guid Property2 { get; set; }
}

public class TestOverriddenClass : TestClass
{
	public new int Property1 { get; set; }
}

what I get creating this descriptor:

var descriptor = new CreateIndexDescriptor("myindex")
	.Mappings(ms => ms
		.Map<TestOverriddenClass>(m => m
			.AutoMap()
		)
	);

is this json:

{
  "mappings": {
    "testoverriddenclass": {
      "properties": {
        "property1": {
          "type": "keyword"
        },
        "property2": {
          "type": "keyword"
        }
      }
    }
  }
}

I know the example classes above are not strictly POCOs, and this is quite a fringe case, but I wanted to know if you plan to support this scenario, because it's quite simple to do with .NET reflection.

[Mpdreamz]

overriding works:

public class TestClass
{
	public virtual Guid Property1 { get; set; }
	public Guid Property2 { get; set; }
}

public class TestOverriddenClass : TestClass
{
	[JsonIgnore]
	public override Guid Property1 { get; set; }
}

then:

	var descriptor = new CreateIndexDescriptor("myindex")
	.Mappings(ms => ms
		.Map<TestOverriddenClass>(m => m
			.AutoMap()
		)
	);
	new ElasticClient().Serializer.SerializeToString(descriptor).Dump();

yields:

{
  "mappings": {
    "testoverriddenclass": {
      "properties": {
        "property2": {
          "type": "keyword"
        }
      }
    }
  }
}

cloaking with new does not as you've found. I think it makes sense to try and support it if it our existing routines do need need a lot of updating.