: I've run into another strange behavior related to LocalParams syntax in
: Solr 1.4.1. If I apply Dismax boosts using bq in LocalParams syntax,
: the contents of the boost queries get used by the highlighter.
: Obviously, when I use bq as a separate parameter, this is not an issue.
...
: Is this a known limitation of the highlighter, or is it a bug? Is this
: issue resolved in newer versions of Solr?
I *think* what you're encountering here is just an inherent property of
how the highlighter works.
HighlightComponent asks the QueryComponent and/or default QParser for the
"highlight query" to extract terms from for highlighting.
With a request like this...
http://localhost:8983/solr/select?defType=dismax&q=solr&hl=true&fl=name&hl.fl=name&bq=server
...DismaxQParser is the default query parser, and because of how it
is designed to work (and designed to be used) it assumes that the "main"
query should just be what's in the "q" param and not the other clauses
like "bq" that were added to it for searching.
In a query like this however...
http://localhost:8983/solr/select?q=inStock:true+AND+_query_:"{!dismax}solr"&hl=true&fl=name&hl.fl=name&bq=server
...LuceneQParser is the default query parser, and it doesn't know/care
what all of the subclauses are, or where they came from, or wether they
are significant enough to the user that they should be included in the
highlighting or not. It just knows that it has a query, so it gives it to
the highlighter.
So it is what it is.
This is definitely an interesting case that i don't think anyone ever
really considered before. It seems like a strong argument in favor of
adding an "hl.q" param that the HighlightingComponent would use as an
override for whatever the QueryComponent thinks the highlighting query
should be, that way people expressing complex queries like you you
describe could do something like...
qq=solr
q=inStock:true AND+_query_:"{!dismax v=$qq}"
hl.q={!v=$qq}
hl=true
fl=name
hl.fl=name
bq=server
...what do you think?
wanna file a Jira requesting this as a feature? Pretty sure the change
would only require a few lines of code (but of course we'd also need JUnit
tests which would probably be several dozen lines of code)
-Hoss
