> I don't know the precedence rules for stored vs. dovValues in Solr DocValues are used if (and only if) all the fields being returned have docValues=“true” _and_ are single-valued, or if you’ve explicitly set useDocValuesAsStored.
single-valued docValues are they only situation where the response is identical between stored and docValues. MultiValued fields have the twin issues of deduplicating input and sorting. The theory is that if you have to decompress the data anyway, it’s likely more efficient to get all the fields from the stored data you can rather than separately go out to read DV fields. > On Aug 27, 2019, at 8:05 AM, Toke Eskildsen <t...@kb.dk> wrote: > > On Tue, 2019-08-27 at 09:05 +0000, Wittenberg, Lucas wrote: >> But the "customid" field is already set as docValues="true" actually. >> Well, I guess so as it is a type="string" which by default has >> docValues="true". >> >> <field name="customid" type="string" indexed="true" stored="true" >> required="true" multiValued="false" /> >> <fieldType name="string" class="solr.StrField" sortMissingLast="true" >> docValues="true" /> > > Yeah, it's a bit confusing. It is both stored and docValues and as far > as I can see, the reader.document-methods only deal with stored. > > Solr masks the difference between stored & docValues for retrieval by > using SolrDocumentFetcher.decoratedocValueFields but Lucene does not do > that for you. The relevant Solr API seems to be > > > https://lucene.apache.org/solr/7_0_1/solr-core/org/apache/solr/search/SolrDocumentFetcher.html#doc-int-java.util.Set > - > > I don't know the precedence rules for stored vs. dovValues in Solr, so > the safe (best performance) solution would be to implement something > like the pseudo code I wrote earlier. > > > - Toke Eskildsen, Royal Danish Library > >
