You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by Dmitri Maziuk <dm...@gmail.com> on 2026/06/02 19:56:08 UTC
order of values in multi-valued fields
Hi all,
I can't find anything in TFM on this: does Solr make any promises about
the order of values in a multi-valued field?
I.e. is it like python containers that keep insertion order until
sorted, SQL resultsets that come in "any order" unless explicitly
sorted, or C "undefined behaviour" that may kill your pets, burn your
house down, and sing limericks over the ashes?
We have plenty of documents that contain ordered lists of images. I
don't see a good way to maintain that order in the Solr document:
- we could make them child documents with "index number" field, but
child documents tend to be a PITA to deal with,
- we could make a delimited "compound" field (e.g. "1:${image}" but that
also requires extra work to render client-side,
- the easy way out is stick them into a multi-valued field but is there
any guarantee that its values will be returned in the order of insertion?
TIA
Dima
Re: order of values in multi-valued fields
Posted by Dmitri Maziuk <dm...@gmail.com>.
On 6/2/26 15:16, Christopher Tate wrote:
> Hello Dima,
>
> A stored field in your managed-schema like this will return Strings in the
> order that they were stored in the array, including duplicate values.
Thank you. That seems to be the "observed" behaviour so far, so that's
what we've been doing, but you gotta wonder...
Thanks again,
Dima
Re: order of values in multi-valued fields
Posted by Christopher Tate <ct...@redhat.com>.
Hello Dima,
A stored field in your managed-schema like this will return Strings in the
order that they were stored in the array, including duplicate values.
<dynamicField name="*_stored_strings" type="strings" indexed="false"
stored="true" multiValued="true" sortMissingLast="true"/>
Docvalues on the other hand, are not guaranteed order, and automatically
remove duplicate values.
<dynamicField name="*_docvalues_strings" type="strings" indexed="true"
stored="true" multiValued="true" sortMissingLast="true" docValues="true"/>
See Retrieving DocValues During Search
<https://solr.apache.org/guide/solr/latest/indexing-guide/docvalues.html>:
While returning non-stored fields from DocValues, the values of a
multi-valued field are returned in sorted order rather than insertion order
and may have duplicates removed, see above. If you require the multi-valued
fields to be returned in the original insertion order, then make your
multi-valued field as stored (such a change requires reindexing).
To your health. Courage!
Christopher Tate
Principal Software Engineer - Red Hat Research
Red Hat Social Innovation Council Architect
Smarta Byar Smart Village FIWARE iHub Founder
ctate@redhat.com
M: +1-385-231-7783
On Tue, Jun 2, 2026 at 2:04 PM Dmitri Maziuk <dm...@gmail.com>
wrote:
> Hi all,
>
> I can't find anything in TFM on this: does Solr make any promises about
> the order of values in a multi-valued field?
>
> I.e. is it like python containers that keep insertion order until
> sorted, SQL resultsets that come in "any order" unless explicitly
> sorted, or C "undefined behaviour" that may kill your pets, burn your
> house down, and sing limericks over the ashes?
>
> We have plenty of documents that contain ordered lists of images. I
> don't see a good way to maintain that order in the Solr document:
>
> - we could make them child documents with "index number" field, but
> child documents tend to be a PITA to deal with,
>
> - we could make a delimited "compound" field (e.g. "1:${image}" but that
> also requires extra work to render client-side,
>
> - the easy way out is stick them into a multi-valued field but is there
> any guarantee that its values will be returned in the order of insertion?
>
> TIA
> Dima
>
>
Re: order of values in multi-valued fields
Posted by Christopher Tate <ct...@redhat.com>.
Hello Dima,
A stored field in your managed-schema like this will return Strings in the
order that they were stored in the array, including duplicate values.
<dynamicField name="*_stored_strings" type="strings" indexed="false"
stored="true" multiValued="true" sortMissingLast="true"/>
Docvalues on the other hand, are not guaranteed order, and automatically
remove duplicate values.
<dynamicField name="*_docvalues_strings" type="strings" indexed="true"
stored="true" multiValued="true" sortMissingLast="true" docValues="true"/>
See Retrieving DocValues During Search
<https://solr.apache.org/guide/solr/latest/indexing-guide/docvalues.html>:
While returning non-stored fields from DocValues, the values of a
multi-valued field are returned in sorted order rather than insertion order
and may have duplicates removed, see above. If you require the multi-valued
fields to be returned in the original insertion order, then make your
multi-valued field as stored (such a change requires reindexing).
To your health. Courage!
Christopher Tate
Principal Software Engineer - Red Hat Research
Red Hat Social Innovation Council Architect
Smarta Byar Smart Village FIWARE iHub Founder
ctate@redhat.com
M: +1-385-231-7783
On Tue, Jun 2, 2026 at 2:04 PM Dmitri Maziuk <dm...@gmail.com>
wrote:
> Hi all,
>
> I can't find anything in TFM on this: does Solr make any promises about
> the order of values in a multi-valued field?
>
> I.e. is it like python containers that keep insertion order until
> sorted, SQL resultsets that come in "any order" unless explicitly
> sorted, or C "undefined behaviour" that may kill your pets, burn your
> house down, and sing limericks over the ashes?
>
> We have plenty of documents that contain ordered lists of images. I
> don't see a good way to maintain that order in the Solr document:
>
> - we could make them child documents with "index number" field, but
> child documents tend to be a PITA to deal with,
>
> - we could make a delimited "compound" field (e.g. "1:${image}" but that
> also requires extra work to render client-side,
>
> - the easy way out is stick them into a multi-valued field but is there
> any guarantee that its values will be returned in the order of insertion?
>
> TIA
> Dima
>
>