On Tue, May 26, 2009 at 1:58 PM, Yonik Seeley <yo...@lucidimagination.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. Hmm -- IndexSearcher tries to detect when SortComparatorSource is used, and drive the search with the toplevel reader, so that code is not supposed to be reached. Do you remember what tickled it? >>> 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. OK >> 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. OK >> But are you now migrating away from Solr's private PQ? (Else you >> wouldn't have hit problems w/ Lucene's new TSDC). > > Yep. Super! > BTW, Kudos to everyone who worked on the new Collector classes... esp > TopFieldCollector.create() - nice powerful stuff, easy to chain with > other collectors, etc. Shai did all the hard work ;) (And, still is...) Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
