I am looking into a similar feature and I also believe SOLR-1105 would potentially be the fix. The reason is that highlighting happens at query time, meaning that the stored field value is first run through the index analyzer and then the search goes through the query analyzer.
On 2021/03/19 20:50:26, gnandre <arnoldbron...@gmail.com> wrote: > This is useful. Thanks, David. > Although in my case, I don't think the solution to the issue you > mentioned resolves the issue. > > Here is why - > I don't want to point to other fields for highlighting but use the same > copy fields destination fields for highlighting. > This is because those copy field destination fields in my case are 'exact > match' fields. So it is important that the highlighting works on those > exact match fields (unstemmed, no synonyms etc). > > Also, in case if I had to point to other fields while highlighting, can't I > just override that with the hl.fl parameter? Basically, use field f1 in qf > param for searching, but use field f2 in hl.fl param? Why is there a need > for contentField param? > > > > On Sun, Mar 14, 2021 at 12:02 AM David Smiley <dsmi...@apache.org> wrote: > > > Good point. Using a different stored field for highlights has been asked > > for; there's a JIRA issue & a patch: > > https://issues.apache.org/jira/browse/SOLR-1105 > > I'm too busy to push this forward by myself but if you can take over there, > > I can work with you (or anyone) to get it in. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Fri, Mar 12, 2021 at 12:32 PM gnandre <arnoldbron...@gmail.com> wrote: > > > > > Hi, > > > > > > I am running into a conflict between two constraints. > > > > > > Atomic updates require copy-field destinations to be stored=false. > > However, > > > if we want to use these copy-field destination fields in highlighting > > then > > > they need to be stored=true. > > > > > > How to resolve this conflict? > > > > > >
