On Tue, May 26, 2009 at 1:44 PM, Michael McCandless
<luc...@mikemccandless.com> wrote:
> On Tue, May 26, 2009 at 12:29 PM, Yonik Seeley
> <yo...@lucidimagination.com> wrote:
>> On Tue, May 26, 2009 at 12:16 PM, Michael McCandless
>> <luc...@mikemccandless.com> wrote:
>>> What other issues are you hitting?
>>
>> I hit an NPE when using old-style sort comparators.
>
> Do you have the traceback (or remember the gist)?
I remember it...
case SortField.CUSTOM:
assert factory == null && comparatorSource != null;
return comparatorSource.newComparator(field, numHits, sortPos, reversed);
comparatorSource was null.
>> The main thing is that I didn't anticipate having to rewrite all the
>> custom sort comparators Solr has.
>
> Because they were loading the FieldCache entry for the entire
> MultiReader (vs normal field sorting which'd load per segment)?
I think that could be it... I didn't trouble myself too long analyzing
it (or the NPE above) - I just figured we should bite the bullet and
start using non-deprecated classes.
> How many custom sort comparators does Solr have?
I guess it's only 3 or 4... plus some code to use them to correctly
merge results in distributed search.
[...]
> But are you now migrating away from Solr's private PQ? (Else you
> wouldn't have hit problems w/ Lucene's new TSDC).
Yep.
BTW, Kudos to everyone who worked on the new Collector classes... esp
TopFieldCollector.create() - nice powerful stuff, easy to chain with
other collectors, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
