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 <[email protected]> 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 <[email protected]> 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? > > >
