is is a bug, right?
>
>
> From: Damien Kamerman
> Sent: Friday, June 16, 2017 12:11:57 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Issue with highlighter
>
> Ali, does adding a 'hl.q' param help? q=something&hl.q=something&
2017 12:11:57 AM
To: solr-user@lucene.apache.org
Subject: Re: Issue with highlighter
Ali, does adding a 'hl.q' param help? q=something&hl.q=something&...
On 16 June 2017 at 06:21, Ali Husain wrote:
> Thanks for the replies. Let me try and explain this a little better.
>
&
91101":{
> "content":["I am adding something to the core field and we
> will try and find it. We want to make sure"]}}
>
> I've tried a bunch of queries. 'adding', 'something' both don't return any
> highlights. 'core
've tried a bunch of queries. 'adding', 'something' both don't return any
highlights. 'core' 'am' 'field' all work.
Am I doing a better job of explaining this? Quite puzzling why this would be
happening. My guess is there is some file
> Beware of NOT plus OR in a search. That will certainly produce no
highlights. (eg test -results when default op is OR)
Seems like a bug to me; the default operator shouldn't matter in that case
I think since there is only one clause that has no BooleanQuery.Occur
operator and thus the OR/AND sho
Just had similar issue - works for some, not others. First thing to look at is
hl.maxAnalyzedChars is the query. The default is quite small.
Since many of my documents are large PDF files, I opted to use
storeOffsetsWithPositions="true" termVectors="true" on the field I was
searching on.
This ce
If the default operator is OR, then you're just matching on the "like"
word and it's being properly highlighted. If you're saying that doc
286 (or whatever) has both "something" and "like" in the content and
you expect to find them both, try increasing the number of snippets
returned.
Otherwise we
