# Inconsistent query behavior with multi\_field and string value **URL:** \ **Category:** Elasticsearch\ **Created:** [December 2, 2013, 7:55am UTC](https://discuss.elastic.co/t/inconsistent-query-behavior-with-multi-field-and-string-value/14655 "2013-12-02T07:55:49Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![zellster](https://avatars.discourse-cdn.com/v4/letter/z/ea666f/32.png) [@zellster](https://discuss.elastic.co/u/zellster)\ **Post date:** [December 2, 2013, 7:55am UTC](https://discuss.elastic.co/t/inconsistent-query-behavior-with-multi-field-and-string-value/14655/1 "2013-12-02T07:55:49Z")
I am seeing inconsistent behavior in ES 0.90.7 when storing a string directly in a multi\_field, versus as a hash of attributes. Relevant gists: > > The only difference in the above two gists is the JSON document published to ES. In the former, the string is directly associated with its value: "name" : "test me" In the latter, the string is associated with a hash which contains its value: ``` "name" : { "value" : "test me" } ``` Performing a search against the multi\_field field without the default name ("name.untouched") returns 1 result in the former, but 0 in the latter. Is this intended? Ref [http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-core-types.html#string](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-core-types.html#string) : The string type also support custom indexing parameters associated with the indexed value. For example: { "message" : { "\_value": "boosted value", "\_boost": 2.0 } } The mapping is required to disambiguate the meaning of the document. Otherwise, the structure would interpret "message" as a value of type "object". The key \_value (or value) in the inner document specifies the real string content that should eventually be indexed. The \_boost (or boost) key specifies the per field document boost (here 2.0). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/7d7fef21-b8fd-4585-9ff9-6df0b4d2734d%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/7d7fef21-b8fd-4585-9ff9-6df0b4d2734d%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![zellster](https://avatars.discourse-cdn.com/v4/letter/z/ea666f/32.png) [@zellster](https://discuss.elastic.co/u/zellster)\ **Post date:** [December 8, 2013, 7:22am UTC](https://discuss.elastic.co/t/inconsistent-query-behavior-with-multi-field-and-string-value/14655/2 "2013-12-08T07:22:12Z")
Copy and paste from > > > I am seeing inconsistent behavior in ES 0.90.7 when storing a string directly in… a multi\_field, versus as a hash of attributes. Relevant gists: > > https://gist.github.com/azell/7746233 > https://gist.github.com/azell/7746253 > > The only difference in the above two gists is the JSON document published to ES. In the former, the string is directly associated with its value: > "name" : "test me" > > In the latter, the string is associated with a hash which contains its value: > "name" : { "value" : "test me" } > > Performing a search against the multi\_field field without the default name ("name.untouched") returns 1 result in the former, but 0 in the latter. Is this intended? Ref http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-core-types.html#string : > > The string type also support custom indexing parameters associated with the indexed value. For example: > > { > "message" : { > "\_value": "boosted value", > "\_boost": 2.0 > } > } > > The mapping is required to disambiguate the meaning of the document. Otherwise, the structure would interpret "message" as a value of type "object". The key \_value (or value) in the inner document specifies the real string content that should eventually be indexed. The \_boost (or boost) key specifies the per field document boost (here 2.0). The culprit looks to be MultiFieldMapper.parse. In theory, the code should rewind the ParserContext to the START\_OBJECT token before calling Mapper.parse. As it is, the second and later Mapper objects receive a ParserContext stuck at the END\_OBJECT token, as the first mapper has consumed additional tokens. Is there a simple way to mark and reset XContentParser, similar to an InputStream? On Sunday, December 1, 2013 11:55:49 PM UTC-8, zellster wrote: > I am seeing inconsistent behavior in ES 0.90.7 when storing a string > directly in a multi\_field, versus as a hash of attributes. Relevant gists: > > [Multi-field and string type working as expected · GitHub](https://gist.github.com/azell/7746233) > [Multi-field and string type with embedded value not working as expected · GitHub](https://gist.github.com/azell/7746253) > > The only difference in the above two gists is the JSON document published > to ES. In the former, the string is directly associated with its value: > "name" : "test me" > > In the latter, the string is associated with a hash which contains its > value: > > ``` > "name" : { "value" : "test me" } > > ``` > > Performing a search against the multi\_field field without the default name > ("name.untouched") returns 1 result in the former, but 0 in the latter. Is > this intended? Ref > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-core-types.html#string:) > > The string type also support custom indexing parameters associated with > the indexed value. For example: > > { > "message" : { > "\_value": "boosted value", > "\_boost": 2.0 > } > } > > The mapping is required to disambiguate the meaning of the document. > Otherwise, the structure would interpret "message" as a value of type > "object". The key \_value (or value) in the inner document specifies the > real string content that should eventually be indexed. The \_boost (or > boost) key specifies the per field document boost (here 2.0). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/e0c8f638-087a-4d88-a88b-3dac2c7c78c7%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/e0c8f638-087a-4d88-a88b-3dac2c7c78c7%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:02am UTC](https://discuss.elastic.co/t/inconsistent-query-behavior-with-multi-field-and-string-value/14655/3 "2017-07-06T02:02:40Z")