You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Jan Høydahl (JIRA)" <ji...@apache.org> on 2016/05/24 13:51:12 UTC
[jira] [Comment Edited] (SOLR-8583) Apply highlighting to
hl.alternateField
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org