You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This happens when fetch fragments using NRTFastVectorHighLighter(fhv).
To reproduce this:
using fhv to highlight a multivalue field
the fragment is at the end of the field
the fragment is from a non-top-matched field
the non-top-matched field is stored in front of the top-matched field
This is a bug from lucene-core, and not fixed in the latest version. (no one reports it)
The bug is caused by the BaseFragmentBuilder.
When processing a multivalue field with the discreteMultiValue toggle on (do not create fragments across the field), the discreteMultiValueHighlighting will be called to reprocess the fragInfos with respect to the multivalue field.
However, when creating the new fragInfos, it doesn't subtract 1 from fragEnd, ending up the fragment actually ends at the first char from the next field.
later on, when creating the fragment string, a boundary scanner will be used to avoid chopping the word at the end of the fragment, so it will continue expanding the end till the end of first word from the next field.
This isn't a concern for the top field, because it is always processed first, plus a coincident of a buffer design and a out-of-boundary fallback mechanism.
The text was updated successfully, but these errors were encountered:
This happens when fetch fragments using NRTFastVectorHighLighter(fhv).
To reproduce this:
using fhv to highlight a multivalue field
the fragment is at the end of the field
the fragment is from a non-top-matched field
the non-top-matched field is stored in front of the top-matched field
This is a bug from lucene-core, and not fixed in the latest version. (no one reports it)
The bug is caused by the BaseFragmentBuilder.
When processing a multivalue field with the
discreteMultiValue
toggle on (do not create fragments across the field), thediscreteMultiValueHighlighting
will be called to reprocess the fragInfos with respect to the multivalue field.However, when creating the new fragInfos, it doesn't subtract 1 from fragEnd, ending up the fragment actually ends at the first char from the next field.
later on, when creating the fragment string, a boundary scanner will be used to avoid chopping the word at the end of the fragment, so it will continue expanding the end till the end of first word from the next field.
This isn't a concern for the top field, because it is always processed first, plus a coincident of a buffer design and a out-of-boundary fallback mechanism.
The text was updated successfully, but these errors were encountered: