[
https://issues.apache.org/jira/browse/SOLR-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745186#action_12745186
]
Robert Muir commented on SOLR-1362:
-----------------------------------
Yonik, in this case I think existing gaps would be preserved with the =
the question is what should the behavior be for tokens that are all delimiters,
currently these are discarded and posInc is incremented for future tokens.
with the current behavior, if you have "LUCENE / SOLR" (all with posInc=1),
this becomes LUCENE (posInc=1), SOLR (posInc=2)
if you change it to =, if you have "LUCENE / SOLR" (pretend SOLR has posInc=3),
the posInc=3 would still be preserved, it would just not become 4.
its clear to me looking at history its been like this for a long time, so maybe
I am incorrect to categorize it as a bug?
But I found this behavior to be a little unexpected, especially for phrase
queries, and given the way the code reads, I wasn't certain if it was
intentional.
> WordDelimiterFilter position increment bug
> ------------------------------------------
>
> Key: SOLR-1362
> URL: https://issues.apache.org/jira/browse/SOLR-1362
> Project: Solr
> Issue Type: Bug
> Components: Analysis
> Reporter: Robert Muir
> Priority: Minor
> Attachments: SOLR-1362.patch
>
>
> WordDelimiterFilter sometimes assigns high position increment values, which
> inhibits phrase matches.
> If this is a feature and not a bug please change the issue type, and I will
> change the patch to propose this as an option...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
