Will do.
Michael McCandless wrote:
OK that looks right.
Though, maybe you should add javadocs to FieldValueHitQueue saying it
does *not* do AUTO resolution? (Since we've deprecated FSHQ in favor
of FVHQ, I think we should call out this difference?). And state the
workaround (calling FVHQ.dete
OK that looks right.
Though, maybe you should add javadocs to FieldValueHitQueue saying it
does *not* do AUTO resolution? (Since we've deprecated FSHQ in favor
of FVHQ, I think we should call out this difference?). And state the
workaround (calling FVHQ.detectFieldType yourself)?
Mike
On Fri,
I'm just putting the auto resolution back in fshq and there is no double
check - foolish me. As I first said, we will either resolve first in
back compat mode and it will be skipped in fshq, or it will be resolved
in fshq for anyone using it externally (and not resolving first on there
own). I'
Eh - we have to spin through all the fields to check for legacy first
anyway. Just doing it twice in legacy mode is probably best? I think
there is no way to avoid spinning through the fields twice in any case
(you have to spin through the sort fields to know you dont want to spin
through the s
Ah, right - thats basically what I was suggesting, though I was thinking
that we might need to resolve twice, but of course your right and we
don't have to. Lucene does still use fshq for back compat (for custom
field source I think?), but I can just do the auto resolution in
IndexSearcher only
Urgh, right. Can't we simply restore the AUTO resolution into it?
Existing (direct) usage of it must be passing in the top-level
IndexReader. (Lucene doesn't use FSHQ internally).
Mike
On Thu, Apr 23, 2009 at 6:48 PM, Mark Miller wrote:
> Just got off the train and ny to ct has a brilliant bar
