[
https://issues.apache.org/jira/browse/SOLR-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15298178#comment-15298178
]
Jan Høydahl edited comment on SOLR-8583 at 5/24/16 1:50 PM:
------------------------------------------------------------
Attaching a first working patch.
There is a new param {{hl.highlightAlternate=true}} which when enabled will
apply the standard highlighter on the alternate field.
We do this by calling {{doHighlightingByHighlighter()}} again on the alternate
field, but with some hardcoded parameters:
{{hl.snippets=1&hl.fragsize=Int.MAX}}. We also set {{hl.maxAnalyzedChars}}
equal to {{hl.maxAlternateFieldLength}} if applicable.
There is one TODO. To be able to override these params, I needed to clone the
{{SolrParams}} object on the request and replace it with a
{{ModifialbleSolrParams}}, and then put back the old. Might not be thread
safe... Perhaps a better way is to add a new {{params}} argument to
doHighlightingByHighlighter?
-Also, I have not tested what happens if people use some other highlighter like
FVH. I suspect that other highlighters may not respect {{hl.pre}}?-
Also, PostingsHighlighter does not support {{hl.alternateField}} at all, and
FVH users specify pre and post using {{hl.tag.pre}} while Simple highlighter
uses {{hl.simple.pre}}, so hardcoding which highlighter to use for the fallback
field would cause problems with these settings not being in sync.
Why cannot all highlighters use the same {{hl.tag.pre/post}} params?
was (Author: janhoy):
Attaching a first working patch.
There is a new param {{hl.highlightAlternate=true}} which when enabled will
apply the standard highlighter on the alternate field.
We do this by calling {{doHighlightingByHighlighter()}} again on the alternate
field, but with some hardcoded parameters:
{{hl.snippets=1&hl.fragsize=Int.MAX}}. We also set {{hl.maxAnalyzedChars}}
equal to {{hl.maxAlternateFieldLength}} if applicable.
There is one TODO. To be able to override these params, I needed to clone the
{{SolrParams}} object on the request and replace it with a
{{ModifialbleSolrParams}}, and then put back the old. Might not be thread
safe... Perhaps a better way is to add a new {{params}} argument to
doHighlightingByHighlighter?
Also, I have not tested what happens if people use some other highlighter like
FVH. I suspect that other highlighters may not respect {{hl.pre}}?
> Apply highlighting to hl.alternateField
> ---------------------------------------
>
> Key: SOLR-8583
> URL: https://issues.apache.org/jira/browse/SOLR-8583
> Project: Solr
> Issue Type: Improvement
> Components: highlighter
> Affects Versions: 5.4
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Fix For: 6.1
>
> Attachments: SOLR-8583.patch
>
>
> Today, you can configure hl.alternateField for highlighter to display if no
> snippets were produced from original field. But the contents of the fallback
> field is output without highlighting the original query terms.
> Suggest that the alternate field is subject to highlighting only, not snippet
> generation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
