I'm not 100% clear; perhaps you could use a hypothetical example where you more clearly state which of f1 or f2 is stored, which way the copyField goes, which field(s) you are already listing in "qf" for search.
It's been awhile since I last looked at that JIRA issue but I'm imagining a feature where the UH might see that a particular hl.fl field is not "stored" yet accommodate this by automatically detecting that this field is the destination of one copyField declaration whose source is "stored", or the reverse -- is copied to some other field that is stored. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Fri, Mar 19, 2021 at 4:50 PM 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? > > > > > >
