Right - the code on this branch is a port from another branch with other
changes, too - among others a modified UninvertingReader that discards
docValues even when FieldInfo claims the field has them (ie it always wraps
when the mapping says so). Even with that change the results are the same.
UninvertingReader#wrap seems to skip uninverting if the field to
uninvert already has doc values of the expected type?
On Tue, Dec 18, 2018 at 8:24 PM Andrzej Białecki
wrote:
>
> The unexpected part is that I would have expected the code to handle
> franken-segments as well, because at some
The unexpected part is that I would have expected the code to handle
franken-segments as well, because at some point we finally resorted to always
forcing the wrapping even for segments that don’t need it (ie. they claim the
field contains DVs) but the test is still failing.
> On 18 Dec 2018,
I had a quick look and couldn't find anything to prevent what you
called “franken-segments” in the Lucene test?
On Tue, Dec 18, 2018 at 5:59 PM Erick Erickson wrote:
>
> A couple of additions:
>
> AddDVMPLuceneTest2 does not use Solr constructs at all, so is the test
> we think is most
A couple of additions:
AddDVMPLuceneTest2 does not use Solr constructs at all, so is the test
we think is most interesting at this point, it won't lead anyone down
the path of "what's all this Solr stuff and is it right" kinds of
questions (believe me, we've spent some time on that path!). Please
Hi,
I'm working on a use case where an existing Solr setup needs to migrate to a
schema that uses docValues for faceting, instead of uninversion. This case fits
into a broader subject of SOLR-12259 (Robustly upgrade indexes). However, in
this case there are two major requirements for this
