Disabling doc values silently ignored

[clintongormley]

If you create a field with doc_values set to false (or not specified), then trying to update the mapping to true throws an exception.

However, if doc_values is initially set to true, then trying to update it to false is silently ignored:

DELETE /t
PUT /t
POST /t/_mapping/t
{
  "properties": {
    "foo": {
      "type": "long",
      "doc_values": true
    }
  }
}

POST /t/_mapping/t
{
  "properties": {
    "foo": {
      "type": "long",
      "doc_values": false
    }
  }
}

GET /t/_mapping

Returns:

{
   "t": {
      "mappings": {
         "t": {
            "properties": {
               "foo": {
                  "type": "long",
                  "doc_values": true
               }
            }
         }
      }
   }
}

[s1monw]

@jpountz I assigned this to you!

[jpountz]

This was actually done on purpose in #4560, see AbstractFieldMapper.merge:

        if (!this.hasDocValues() && fieldMergeWith.hasDocValues()) {
            // don't add conflict if this mapper has doc values while the mapper to merge doesn't since doc values are implicitely set
            // when the doc_values field data format is configured
            mergeContext.addConflict("mapper [" + names.fullName() + "] has different " + TypeParsers.DOC_VALUES + " values");
        }

If we did not add a conflict, this would mean that if you initially create your mappings with just fielddata.format=doc_values and later perform a mapping update with fielddata.format=array, you would get an exception because the mapping update doesn't have doc values enabled. Is it the expected behaviour?

[clintongormley]

@jpountz - I don't understand the doc_values vs array comment, but I think we should at least report what we accept and what we don't. So I'm happy for the attempt to disable doc_values to return an exception, rather than being silently ignored.

[jpountz]

This has been fixed by @rjernst in the recent mappings fixes.