[
https://issues.apache.org/jira/browse/SOLR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793655#action_12793655
]
Robert Muir commented on SOLR-1670:
-----------------------------------
bq. I don't think assertTokEqual really has a bug - it's written more to match
lucene queries and indexes, not to exactly compare one token stream with
another. So a singe ab token matches multiple ab tokens at the same position.
Seriously, I think if you want to test these things, then the assertQ etc
should be used (actually run queries and test results) instead.
But this is a bug, because aa is not the same as aa,aa(pos=0),aa(pos=0), not
even for "queries and indexes".
This is because the latter will affect the score of the search.
I think this is right in line with what you are saying in SOLR-1674, that you
have somehow lost some flexibility: This is not true
* these things are different, the tokenstream output is different, things such
as score change
* if you don't like this, and instead want to test queries, then do just that,
instead of examining tokenstreams.
> 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_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.
