Michael McCandless wrote:

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?

Mike
Your right. I get caught up in the mode of trying to hack it to work quick before I do it right.

- Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to