lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: [jira] Commented: (LUCENE-831) Complete overhaul of FieldCache API/Implementation
Date Tue, 09 Dec 2008 10:13:18 GMT

Mark Miller wrote:

> Mark Miller wrote:
>> Mark Miller wrote:
>>>> Which new sort stuff are you referring to?  Is it LUCENE-1471?
>>> Yes. First thing I did was try and patch this in, but the sort  
>>> tests failed. It would be the right order, but like the two center  
>>> docs would be reversed or something. No time to dig in, so I just  
>>> switch to the trunk MultiSearcher and all tests passed except for  
>>> the two with the above issues.
>> Got the auto detection working though.
> Bah, I didn't. Brought up an old bug I've seen before - if you use  
> multisearcher and an index doesn't have the field, AUTO won't work.  
> Advice I always got was don't use AUTO, but even Lucene uses it  
> internally. Thought I had a workarount, but didn't quite work. Not  
> sure what to do about this one - I'll have to mull it and the ids  
> issue over a bit I suppose.

Hmm... I think we have to keep the AUTO -> true type resolution that  
MultiReader would do?  Ie, ask MultiReader for the TermEnum, not the  
first sub-reader, for resolving.

In fact we should factor out an explicit method to do this; it's  
currently in ExtendedFieldCache.autoCache.createValue.

As long as you do that resolving up front w/ the MultiReader, and pass  
only resolved SortField[] to each sub-reader, that should fix it?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message