Return values for Hit#stored
Mat Brown
Currently, the #stored method of the Hit object follows this logic:
- If no value is stored for the field, return nil
- If one value is stored for the field (even if it is a multi-valued
field), return that value
- If multiple values are stored for the field, return an array of those values.
This isn't entirely intentional, particularly with respect to
multi-valued fields; it's just the way it works now. Clearly, there's
an argument that for multi-valued fields, the return value of #stored
should always be an array -- an empty one if there's nothing stored,
and a one-element array if one value is stored. This came up in this
ticket: http://outoftime.lighthouseapp.com/projects/20339/tickets/118-stored-attribute-whose-value-is-an-empty-array-stores-nil-instead-of-an-empty-array
While there is an argument to making a change, there are a couple of
arguments against:
* All text fields are implicitly multi-valued; that means that this
would be changing the API for a nontrivial set of use cases.
* It's possible to have a fulltext field and an attribute field with
the same name; if only one is multi-valued, then there's no obvious
answer to what we should return in the case that neither has a stored
value.
So: thoughts, folks?
Mat
Toby M
> * All text fields are implicitly multi-valued; that means that this
> would be changing the API for a nontrivial set of use cases.
> * It's possible to have a fulltext field and an attribute field with
> the same name; if only one is multi-valued, then there's no obvious
> answer to what we should return in the case that neither has a stored
> value.
hit.stored(:attribute_the_isnt_really_stored) always return nil? I
think this makes sense. It's different if you store an empty array; in
this case I expect hit.stored(:field) to return [].
Mat Brown
>
>> * All text fields are implicitly multi-valued; that means that this
>> would be changing the API for a nontrivial set of use cases.
>
> Can you go into a more detail on this?
With no stored value:
hit.stored(:some_text_field) #=> nil (now)
hit.stored(:some_text_field) #=> [] (proposed)
With one stored value:
hit.stored(:some_text_field) #=> "some value" (now)
hit.stored(:some_text_field) #=> ["some value"] (proposed)
With multiple stored values:
hit.stored(:some_text_field) #=> "first value" (now, obviously wrong)
hit.stored(:some_text_field) #=> ["first value", "second value"] (proposed)
>
>> * It's possible to have a fulltext field and an attribute field with
>> the same name; if only one is multi-valued, then there's no obvious
>> answer to what we should return in the case that neither has a stored
>> value.
>
> If _no_ field is stored, doesn't
> hit.stored(:attribute_the_isnt_really_stored) always return nil? I
> think this makes sense. It's different if you store an empty array; in
> this case I expect hit.stored(:field) to return [].
There's actually no concept of "storing an empty array" -- when a Solr
document is indexed, each field has zero, one, or more values. If your
Sunspot data accessor returns an empty array, Sunspot simply doesn't
index anything for that field. So at search time, what Sunspot sees is
just that there are no stored values for that array.
FYI all, at this point I'm leaning toward making the change such that
multivalued fields (including all text fields) return an array for the
#stored method. This is a pretty significant API change and will
probably cause some pain in client applications, but the way things
stand now is clearly a bug and this is the only fix I can think of
that would give you a remotely consistent API. This change would go
out in Sunspot 1.2. I'm still open to persuasion or suggestions of a
third way, of course, so pipe up if you've got an opinion!
Mat
>
> --
> You received this message because you are subscribed to the Google Groups "Sunspot" group.
> To post to this group, send email to ruby-s...@googlegroups.com.
> To unsubscribe from this group, send email to ruby-sunspot...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ruby-sunspot?hl=en.
>
>
