Thanks David.
So I guess I will have to go with default highlighter (with a higher
fragsize) and then take care of boundryScanning myself.
Ah. Currently the most accurate highlighter is the default one, so if
accuracy is more important than BreakIterator then you’ll have to switch
back. Keep an eye out for some efficiency enhancements to this highlighter
“real soon now”. Separately from that efficiency, later this year I may
have a
Yes. It seems to work for Default Highlighting. I'm using Fast Vector
Highlighter.
Let me also explain why I went for Fast Vector Highlighter. I wanted the
highlighted content to be complete and not broken words and for that I
need to use breakIterator which works only for Fast vector highlightin
John,
I’m not seeing this problem. Presumably we’re talking about the default
highlighter (the most accurate one) but I figure the others would match it
too. To test, I added the following to HighlightTest.java in Solr and this
test passed:
@Test
public void testSpan() {
final String fie
Well, maybe you can work with the ComplexPhraseQueryParser, that's
been around for a while, see:
http://lucene.apache.org/core/4_10_1/queryparser/org/apache/lucene/queryparser/complexPhrase/ComplexPhraseQueryParser.html
Or you can just live with the inherent slop in the ~ operator. You
haven't rea
I have this line highlighted
Jobs was born in San Francisco, California on February
24 1955.
for query "Jobs born"~15 but not for "born Jobs"~15. I want the same result
irrespective of the order of search keywords.
Regards,
John Eipe
“The Roots of Violence: Wealth without work, Pleasure withou
Well, the syntax is wrong. You probably want content_raw:"jobs
born"~15. The way slop works, it is the number of "moves" so this will
match "jobs was a man born somewhere" and "all persons born include
jobs". The difference is that the version that has "born" first and
"jobs" second will take an ex
