lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin Rzewucki <mrzewu...@gmail.com>
Subject Re: DocValues and field requirements
Date Fri, 22 Mar 2013 09:34:31 GMT
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 <solr@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message