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) > > >> > > > > > > > >
