Make GetField behavior more consitent for multivalued fields.

[imotov]

Before this change, the GetField#getValue() method was returning a list of values of a multivalued fields if the field values were obtained from source or if the field was stored and real-time get was used. If the field was stored but non-realtime get was used, GetField#getValue() was returning only the first element and the GetField#getValues() was returning a list of elements. This change makes behavior consistent. GetField#getValue() now always returns only the first value of the field and GetField#getValues() returns the entire list.

[kimchy]

Looks good!, lets backport to 0.90 as well.

[btiernay]

For nested types, what should be the expected behavior here? After upgrading to 0.90.1 our ES client code broke semantically since now getValue only returns the first nested doc. However, there is now no way to determine at query time if the value should be single value or not without knowing the mapping.

Even if the mapping is known, there is no way to distinguish an array object type from an "object" object type. This makes it very difficult to proxy elasticsearch queries dynamically (ex. dynamically created queries for which you wouldn't know until runtime which fields are returned ), and requires access to the mapping and manually maintained metadata to know which method to call for a single vs multivalue field.

[btiernay]

I thought about this a little more. Would it be possible to add a new method to GetField such as isMultiValued to return whether or not the field is mapped as having multiple values? This would be similar to LongValues, DoubleValues, BytesValues, etc. This would be a suitable compromise for both consistency and general usage.

[btiernay]

@imotov: Just curious to your thoughts on this. We don't really have a good solution for working around this right now. Is there another mechanism I'm overlooking? Thank again.

[imotov]

@btiernay I don't think I fully understand the problem. In elasticsearch any field can be multivalued. There is no "array" type because any field can accept and array of values. Are you trying to distinguish between an array that contains one element and a single element that wasn't passed to elasticsearch as an array? If not, could you provide some examples?

[btiernay]

@imotov: I'm trying to distinguish x (non-nested) in the following document:

{x: [1, 2, 3]}

from:

{x: 1}

So that when a query requesting x be returned, it is known that getValue or getValues should be called. At design time this is known, but at query time it is not.

What I am getting from you is that since ES makes no distinction between the two, it is up to the application to manage this information. Is that correct?

[imotov]

There is a difference between {"x": [1,2,3]} and {"x": 1}, for the first record GetField#getValues() returns a list with 3 elements and for the second with only 1. However, there is currently no way to distinguish between {"x": [1]} and {"x": 1}.

[kimchy]

@btiernay there isn't a way today, but we are going to support it pretty soon. In search we actually support it with teh concept of partial fields, and we plan to add it to get, and actually simplify partial fields even more.

[btiernay]

@imotov: Thanks for the explanation.
@kimchy: Thanks for the update. Is there a ticket I can follow to be sure that I don't miss it?

[kimchy]

@btiernay I don't think we have a ticket open yet, there should be one open pretty soon where we can brainstorm if needed.

[btiernay]

@kimchy: Awesome thanks again for such a great product :)

[btiernay]

@kimchy Was the feature you mentioned in your previous message ever added? We are struggling with this issue now that we are upgrading from 0.90.1 to 1.4. Cheers.

[bleskes]

@btiernay, yeah- look for source filtering http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-source-filtering.html