MapFromAttributes not working with Enum fields

The MapFromAttributes is not working when the class includes an enum. Here is a simple example:

    public void InitializeES()
    {
        //drop the index for debugging purposes, remove this later
        var deleteResponse = _client.DeleteIndex(f => f.Index(_client.Infer.DefaultIndex));
        VerifyResponse(deleteResponse);
        if (!_client.IndexExists(i => i.Index(_client.Infer.DefaultIndex)).Exists)
        {
            var response = _client.CreateIndex(_client.Infer.DefaultIndex);
            VerifyResponse(response);
        }
        VerifyResponse(_client.Map<TestClass>(m => m.MapFromAttributes()));
    }

    private static void VerifyResponse(IResponse response)
    {
        if (!response.IsValid)
        {
            throw new ElasticsearchServerException(response.ServerError);
        }
    }

    [ElasticType(Name = "testclass")]
    public class TestClass
    {
        public int Id { get; set; }

        [ElasticProperty(Index = FieldIndexOption.NotAnalyzed)]
        [JsonConverter(typeof(StringEnumConverter))]
        public EnumTester EnumTest { get; set; }
    }

    public enum EnumTester
    {
        Value1,
        Value2
    }

This is the resulting structure from calling GET testindex/_mapping:

{ “testindex”: { “mappings”: { “testclass”: { “properties”: { “id”: { “type”: “integer” } } } } } }

The enum is missing from the mapped data structure.

I’m on ES 1.3.0, NEST 1.0.2

Am I doing something wrong or is this a bug?

Thanks in advance guys, I love ES and I love NEST!

[bloritsch]

Weighing in here, as the guy who was blindsided by this issue and asked the question.

We are talking about documents, not POCO objects. How the runtime stores and works with enums is irrelevant from a document standpoint. What’s important is what those numbers convey, and that meaning is expressed in words. I would argue for storing the enum as a string, the way that ElasticSearch 1.4.x does now.

I would go a step further, and when you automap based on types, all enums would be treated as strings that are not analyzed. The number of values an enum can hold is finite, and they should never be tokenized and split apart (i.e. with underscores, etc.). Feel free to prove me wrong, but I would argue enum types would be most often used with terms filters.

[gmarz]

We can either default to integer, string, or throw an exception. I’m torn- defaulting to integer seems technically correct, since that’s how enums are treated naturally. On the other hand, I think most people are expecting/want a string. Thoughts @Mpdreamz ?