[
https://issues.apache.org/jira/browse/SOLR-11801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306270#comment-16306270
]
Christine Poerschke commented on SOLR-11801:
--------------------------------------------
Thanks David for the quick reply!
bq. If the point here to make it easier for Solr plugin authors (a subset of
Solr users) to customize the highlighting response ... Or if the objective is
to also provide a hl.collator param ...
Whilst the two objectives are not mutually exclusive the main point was for
easier customisation and for the hl.collator param to be added only _if_ easier
customisation is not enough of an objective in its own right _or_ because there
is demand for a hl.collator param.
bq. ... I've been kicking around an idea ... Why set aside highlighting in the
Solr response when it's per-document information – it ought to go in the
document response!
That's a great idea, having the highlights on a per-document basis will make
things easier for Solr clients i.e. no need to fold the highlighting response
into the main response or to pass around two separate response elements.
Okay, given that customisation of the highlighting response is probably a
relatively niche use case and on the assumption that in future the highlighting
response element could go away in favour of per-document highlights, then the
introduction of a new hl.collator param doesn't quite make sense in my opinion
and only the easier customisation objective remains.
bq. ... wouldn't it be simpler to add a few protected methods to
HighlightComponent and suggest it be subclassed, instead of adding a new
abstraction "HighlightCollator"? ...
The patch proposes just the one new protected method to obtain a collator
object; the collator object then defines the methods used in collating and it's
(hopefully) clear that way that the
convertHighlights/addHighlights/getAllHighlights methods need to operate in
concert.
The collator abstraction could be removed and as you put it "a few protected
methods" be added directly instead. This would be less clear in terms of code
structure though I think; the collator is a combination of its methods _and_ a
supporting data structure with the custom collator using a different data
structure type.
Sigh, writing that made me realise that with the collator containing (per
request) state it should not be a member of the highlight component itself, per
request state such as the doHighlights flag is stored in the ResponseBuilder
but intuitively I'm reluctant to add a highlightCollator field to the
ResponseBuilder class ... okay, some more thinking needed ...
bq. BTW it would be nice if the highlight component's response was restructured
to optionally allow returning richer information – see SOLR-1954 (return char
offsets). Certainly not to be tackled in this issue but just want to share.
Thanks for sharing! So richer information could then mean being able to
distinguish a snippet early on in the text from a snippet that is later on in
the text, yes, that makes sense to me as a use case, though yes out of scope
for this issue here.
> support customisation of the "highlighting" query response element
> ------------------------------------------------------------------
>
> Key: SOLR-11801
> URL: https://issues.apache.org/jira/browse/SOLR-11801
> Project: Solr
> Issue Type: New Feature
> Components: highlighter
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
> Priority: Minor
> Attachments: SOLR-11801.patch
>
>
> The objective and use case behind the proposed changes is to be able to
> receive not the out-of-the-box highlighting map
> {code}
> {
> ...
> "highlighting" : {
> "MA147LL/A" : {
> "manu" : [
> "<em>Apple</em> Computer Inc."
> ]
> }
> }
> }
> {code}
> as illustrated in
> https://lucene.apache.org/solr/guide/7_2/highlighting.html#highlighting-in-the-query-response
> but to be able to customise the highlighting element of the query response
> to (for example) be like this
> {code}
> {
> ...
> "highlighting" : [
> {
> "id" : "MA147LL/A",
> "snippets" : {
> "manu" : [
> "<em>Apple</em> Computer Inc."
> ]
> }
> }
> ]
> }
> {code}
> where the highlighting element itself is a list and where the keys of each
> list element are 'knowable' in advance i.e. they are not 'unknowable'
> document ids.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
