I switched over to using FastVectorHighlighting, and the problem with
maxBooleanClause is resolved. I guess this is at the expense of having
a larger index (since you have to enable termVectors, termPositions and
termOffsets), but at least it's working.
Thanks for the help.
Mike
On Tue 03 Jan 2012 11:53:35 AM PST, Chris Hostetter wrote:
: About bumping MaxBooleanQueries. You can certainly
: bump it up, but it's a legitimate question whether the
: user is well served by allowing that pattern as opposed
: to requiring 2 or 3 leading characters. The assumption
i think the root of the issue here is that when executing queries, really
broad prefix queries like "q=*" generate constant score queries, so relaly
broad prefix queries are "safe" to execute. but (based on his error) it
seems like the highlighter fails loudly an painfully on these otherwise
"safe" queries.
understandably, part of the reason this happens is that the highlighter
needs to know all the terms that that prefix expands to in order to know
what to highlight, but the fact that it generates an error when
maxBooleanClause is hit seems unfortunate -- maybe there is no way arround
it, but i *thought* there were options that could be used related to
highlighting to mitigate these issues, i just couldn't remember what they
are (does the FastVectorHighlighter have these problems? is it only if you
use WeightedSpanTermExtractor?) and hence my suggestion to Michael to
start a thread here in the hopes that the highlighting experts (Yeah Koji!
... better you then me!) would chime in.
-Hoss
