[
https://issues.apache.org/jira/browse/SOLR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829092#action_12829092
]
Robert Muir commented on SOLR-1670:
-----------------------------------
bq. Order of overlapping tokens is unimportant in every TokenFilter used in
Solr that I know about. Order-sensitivity is the exception, no?
I guess all along my problem is that tokenstreams are ordered by definition. if
this order does not matter, a test that uses actual queries would make more
sense.
The problem was that the test constructions previously used by this filter were
used in other places where they really shouldn't have been, and the laxness hid
real bugs (such as this very issue itself!!!).
This is all I am trying to avoid. There is nothing wrong with Steven's
patch/test construction, just trying to err on the side of caution.
> synonymfilter/map repeat bug
> ----------------------------
>
> Key: SOLR-1670
> URL: https://issues.apache.org/jira/browse/SOLR-1670
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
> Affects Versions: 1.4
> Reporter: Robert Muir
> Assignee: Yonik Seeley
> Attachments: SOLR-1670.patch, SOLR-1670.patch, SOLR-1670_test.patch
>
>
> as part of converting tests for SOLR-1657, I ran into a problem with
> synonymfilter
> the test for 'repeats' has a flaw, it uses this assertTokEqual construct
> which does not really validate that two lists of token are equal, it just
> stops at the shorted one.
> {code}
> // repeats
> map.add(strings("a b"), tokens("ab"), orig, merge);
> map.add(strings("a b"), tokens("ab"), orig, merge);
> assertTokEqual(getTokList(map,"a b",false), tokens("ab"));
> /* in reality the result from getTokList is ab ab ab!!!!! */
> {code}
> when converted to assertTokenStreamContents this problem surfaced. attached
> is an additional assertion to the existing testcase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
