I’m a little amused that this thread has become active after almost two months of silence.
I think we just used the old highlighter. I don’t even remember now. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On May 23, 2020, at 9:14 AM, Anthony Groves <agro...@oreilly.com> wrote: > > Hi Walter, > > I did something very similar to what David is suggesting when switching > from the PostingsHighlighter to the UnifiedHighlighter in Solr 7. > > In order to include non-highlighted items (exact ordering) when using > preserveMulti, we used a custom PassageFormatter that ignored the start and > end offsets: > https://github.com/oreillymedia/ifpress-solr-plugin/blob/bf3b07c5be32fbcfa7b6fdfd439d511ef60dab68/src/main/java/com/ifactory/press/db/solr/highlight/HighlightFormatter.java#L35 > > I was actually surprised to see not much of a performance hit from > essentially removing the offset usage, but our highlighted fields aren't > extremely large :-) > > Hope that helps! > Anthony > > *Anthony Groves* | Technical Lead, Search > > O'Reilly Media, Inc. | https://www.linkedin.com/in/anthonygroves/ > > > On Fri, May 22, 2020 at 4:59 PM David Smiley <david.w.smi...@gmail.com> > wrote: > >> Hi Walter, >> >> No, the UnifiedHighlighter does not behave as if this setting were true. >> >> The docs say: >> >> `hl.preserveMulti`:: >> If `true`, multi-valued fields will return all values in the order they >> were saved in the index. If `false`, the default, only values that match >> the highlight request will be returned. >> >> >> The first sentence there is the essence of it. Notice it's not conditional >> on wether there are highlights or not. The UH won't return values lacking >> a highlight. Even hl.defaultSummary isn't triggered because *some* of the >> values have a highlight. >> >> As I look at the pertinent code right now, I imagine a solution would be to >> provide a custom PassageFormatter. If we can assume for this use-case that >> you can use hl.bs.type=WHOLE as well, then a a simpler PassageFormatter >> could basically ignore the passage starts & ends and merely mark up the >> original content in entirety, which is a null concatenated sequence of all >> the values for this field for a document. >> >> ~ David >> >> >> On Fri, Mar 29, 2019 at 2:02 PM Walter Underwood <wun...@wunderwood.org> >> wrote: >> >>> We are testing 6.6.1. >>> >>> wunder >>> Walter Underwood >>> wun...@wunderwood.org >>> http://observer.wunderwood.org/ (my blog) >>> >>>> On Mar 29, 2019, at 11:02 AM, Walter Underwood <wun...@wunderwood.org> >>> wrote: >>>> >>>> In testing, hl.preserveMulti=true works with the unified highlighter. >>> But the documentation says that the parameter is only implemented in the >>> original highlighter. >>>> >>>> Is the documentation wrong? Can we trust this to keep working with >>> unified? >>>> >>>> wunder >>>> Walter Underwood >>>> wun...@wunderwood.org >>>> http://observer.wunderwood.org/ (my blog) >>>> >>>>> On Mar 26, 2019, at 12:08 PM, Walter Underwood <wun...@wunderwood.org >>> >>> wrote: >>>>> >>>>> It looks like hl.preserveMulti is only implemented in the Original >>> highlighter. Has anyone looked at doing this for the Unified highlighter? >>>>> >>>>> We need to preserve order in the highlights for a multi-valued field. >>>>> >>>>> wunder >>>>> Walter Underwood >>>>> wun...@wunderwood.org <mailto:wun...@wunderwood.org> >>>>> http://observer.wunderwood.org/ (my blog) >>>>> >>>> >>> >>> >>
