MapperParsingException[Wrong value for index [yes] for field [...]]

[kohanyirobert]

I get the following error MapperParsingException[Wrong value for index [yes] for field [date]], when I try to put the following mapping into my totally new and empty index (created with curl -XPUT http://localhost:9200/myindex/).

curl -XPUT http://localhost:9200/myindex/mytype/_mapping -d ' {
  "mytype": {
    "properties": {
      "date": {
        "type": "long",
        "store": "yes",
        "index": "yes",
        "omit_norm": "yes",
        "omit_term_freq_and_positions": "yes"
      }   
    }   
  }
}'

Setting index to no works.

In Java using Lucene 3.6.0 I can do the following:

NumericField f = new NumericField("date", Field.Store.Yes, true);
f.setOmitNorms(true);
f.setOmitTermFreqAndPositions(true);
f.setLongValue(1L);

Document d = new Document();
d.add(f);

From this (and the documentation here, which doesn't mention that it's illegal what I'm trying to do) I assume what I'm trying to do is doable.

(I realize that elasticsearch has a date type, but I must use the mapping mentioned above.)

[clintongormley]

curl -XPUT http://localhost:9200/myindex/mytype/_mapping -d ' {
  "mytype": {
    "properties": {
      "date": {
        "type": "long",
        "store": "yes",
        "index": "yes",
        "omit_norm": "yes",
        "omit_term_freq_and_positions": "yes"
      }   
    }   
  }
}'

Setting index to no works.

In Java using Lucene 3.6.0 I can do the following:

NumericField f = new NumericField("date", Field.Store.Yes, true);
f.setOmitNorms(true);
f.setOmitTermFreqAndPositions(true);
f.setLongValue(1L);

Document d = new Document();
d.add(f);

From this (and the documentation
here, which doesn't mention that it's illegal what I'm trying to do) I assume what I'm trying to do is doable.

The allowed values for "index" are "no", "not_analyzed" and "analyzed"

(I realize that elasticsearch has a date type, but I must use the
mapping mentioned above.)

Why? Given that that is pretty much exactly what the 'date' field maps
to.

Also, why are you storing the field? Each stored field means another
disk seek, which is slow. By default the _source field is stored,
meaning that you can retrieve the whole doc almost as quickly as you can
retrieve a single stored field.

clint

[kohanyirobert]

The allowed values for "index" are "no", "not_analyzed" and "analyzed"

Okay, you're right, thanks for the heads up. Reading ES's documentation on numeric fields I somehow assumed that an index mapping's value can only be no or yes, because the possible values wasn't listed beside mapping field's documentation.

Also, why are you storing the field?

Did you ever hear about legacy code? :)

Thanks for the help.

[kimchy]

@kohanyirobert in Lucene, there isn't really a meaning for analysis on numeric fields, so in ES, analyzed and not_analyzed is the same for numeric fields, meaning, "indexed", and no means not indexing it.

[kohanyirobert]

@kimchy Yeah, I've already managed to figure this out. What lead me astray was that the legacy code I'm porting to ES created Lucene numeric fields using a constructor which takes a boolean argument named index. From this (and from the documentation) it was evident for me that a numeric field can be indexed (yes) and not indexed (no).

[patelatharva]

So the conclusion is we can only use 'analyzed','not_analyzed' or 'no' with index for date and numeric fields; and shouldn't use 'yes', right?! (if it is so then why the documentation is not reflecting the same! : ( )

[Mpdreamz]

Core type documentation does indeed mention yes, no as the only two valid options for date, numeric and boolean index values.

http://www.elasticsearch.org/guide/reference/mapping/core-types.html

and

http://www.elasticsearch.org/guide/reference/mapping/type-field.html could make a better mention of possible values as well.

[intoraw]

i think the document of http://www.elasticsearch.org/guide/reference/mapping/core-types.html on boolean and long types has a mistake. "yes" should be "not_analyzed" or "analyzed".

[cutalion]

@zorksylar, you're so right!

[eranid]

@clintongormley you suggest not setting store to true, but the documentation for number and boolean suggest it should be set to "yes" if index is set to "no". It further says otherwise there is nothing we can do with it.
Should it not be in the "_source" anyway, even if both are set to "no"?