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]
