[
https://issues.apache.org/jira/browse/SOLR-12136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16416231#comment-16416231
]
David Smiley commented on SOLR-12136:
-------------------------------------
Here is no language for hl.fl, hl.q, hl.qparser:
{noformat}
`hl.fl`::
Specifies a list of fields to highlight, either comma- or space-delimited.
A wildcard of `\*` (asterisk) can be used to match field globs, such as
`text_*` or even `\*` to highlight on all fields where highlighting is
possible.
When using `*`, consider adding `hl.requireFieldMatch=true`.
+
Note that the field(s) listed here ought to have compatible text-analysis
(defined in the schema) with field(s) referenced in the query to be
highlighted.
It may be necessary to modify `hl.q` and `hl.qparser` and/or modify the text
analysis.
The following example uses the
<<local-parameters-in-queries.adoc,local-params>> syntax and
<<the-extended-dismax-query-parser.adoc,the edismax parser>> to highlight
fields in `hl.fl`:
`&hl.fl=field1 field2&hl.q={!edismax qf=$hl.fl
v=$q}&hl.qparser=lucene&hl.requireFieldMatch=true` (along with other applicable
parameters, of course).
+
The default is the value of the `df` parameter which in turn has no default.
`hl.q`::
A query to use for highlighting.
This parameter allows you to highlight different terms or fields than those
being used to search for documents.
When setting this, you might also need to set `hl.qparser`.
+
The default is the value of the `q` parameter (already parsed).
`hl.qparser`::
The query parser to use for the `hl.q` query. It only applies when `hl.q` is
set.
+
The default is the value of the `defType` parameter which in turn defaults to
`lucene`.
{noformat}
> Document hl.q parameter
> -----------------------
>
> Key: SOLR-12136
> URL: https://issues.apache.org/jira/browse/SOLR-12136
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
> Fix For: 7.4
>
> Attachments: SOLR-12136.patch
>
>
> *********Original issue:
> If I specify:
> hl.fl=f1&hl.q=something
> then "something" is analyzed against the default field rather than f1
> So in this particular case, f1 did some diacritic folding
> (GermanNormalizationFilterFactory specifically). But my guess is that
> the df was still "text", or at least something that didn't reference
> that filter.
> I'm defining "worked" in what follows is getting highlighting on "Kündigung"
> so
> Kündigung was indexed as Kundigung
> So far so good. Now if I try to highlight on f1
> These work
> q=f1:Kündigung&hl.fl=f1
> q=f1:Kündigung&hl.fl=f1&hl.q=Kundigung <= NOTE, without umlaut
> q=f1:Kündigung&hl.fl=f1&hl.q=f1:Kündigung <= NOTE, with umlaut
> This does not work
> q=f1:Kündigung&hl.fl=f1&hl.q=Kündigung <= NOTE, with umlaut
> Testing this locally, I'd get the highlighting if I defined df as "f1"
> in all the above cases.
> **********David Smiley's analysis
> BTW hl.q is parsed by the hl.qparser param which defaults to the defType
> param which defaults to "lucene".
> In common cases, I think this is a non-issue. One common case is
> defType=edismax and you specify a list of fields in 'qf' (thus your query has
> parts parsed on various fields) and then you set hl.fl to some subset of
> those fields. This will use the correct analysis.
> You make a compelling point in terms of what a user might expect -- my gut
> reaction aligned with your expectation and I thought maybe we should change
> this. But it's not as easy at it seems at first blush, and there are bad
> performance implications. How do you *generically* tell an arbitrary query
> parser which field it should parse the string with? We have no such
> standard. And lets say we did; then we'd have to re-parse the query string
> for each field in hl.fl (and consider hl.fl might be a wildcard!). Perhaps
> both solveable or constrainable with yet more parameters, but I'm pessimistic
> it'll be a better outcome.
> The documentation ought to clarify this matter. Probably in hl.fl to say
> that the fields listed are analyzed with that of their field type, and that
> it ought to be "compatible" (the same or similar) to that which parsed the
> query.
> Perhaps, like spellcheck's spellcheck.collateParam.* param prefix,
> highlighting could add a means to specify additional parameters for hl.q to
> be parsed (not just the choice of query parsers). This isn't particularly
> pressing though since this can easily be added to the front of hl.q like
> hl.q={!edismax qf=$hl.fl v=$q}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
