Hi Shawn, Thank you for your response. Yes, that's strange. By enabling DocValues the information about missing fields is lost, which changes the way of sorting as well. Adding default value to the fields can change a logic of application dramatically (I can't set default value to 0 for all Trie*Fields fields, because it could impact the results displayed to the end user, which is not good). It's a pity that using DocValues is so limited.
Regards. On 21 March 2013 22:29, Shawn Heisey <s...@elyograg.org> wrote: > On 3/21/2013 3:07 PM, Shawn Heisey wrote: > >> This might be a requirement of the lower-level Lucene API, or it might >> be a requirement that was instituted at the Solr level because a problem >> was found when docs did not contain the field. Google seems reluctant >> to tell me, and I haven't figured out the right way to ask. >> > > Some poking around the Lucene API has turned up an interesting notation on > all the different types on DocValues: > > http://lucene.apache.org/core/**4_1_0/core/org/apache/lucene/** > index/DocValues.Type.html#**FIXED_INTS_16<http://lucene.apache.org/core/4_1_0/core/org/apache/lucene/index/DocValues.Type.html#FIXED_INTS_16> > > They all say that if a value isn't present, zero (or an empty string) is > assumed, and that there is no way to distinguish this from the same value > that is intentionally indexed. > > So it appears that Solr *could* use docValues without the "required or > default value" restriction, but there is a strong possibility that the > behavior will not be what the user expects. When docValues is not turned > on, there is a clear difference between a default value and a missing > field. The sort mechanism without docValues can sort documents with the > field missing either before or after the other values. That would be > impossible with docValues. > > By including the restriction, the dev team has made it less likely that > the Solr admin will be surprised by the new behavior, because they have to > change the field definition to make docValues work. > > Thanks, > Shawn > >
