[
https://issues.apache.org/jira/browse/SOLR-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933023#comment-15933023
]
Steve Rowe commented on SOLR-10264:
-----------------------------------
bq. multi-term origins in the query are problematic for unrelated reasons.
FYI I committed SOLR-9185 last week. It adds the {{sow}} (split-on-whitespace)
param to the edismax and standard/"Lucene" query parsers, which when set to
{{false}} will allow query-time multi-term origins.
> ManagedSynonymFilterFactory does not parse multi-term synonyms
> --------------------------------------------------------------
>
> Key: SOLR-10264
> URL: https://issues.apache.org/jira/browse/SOLR-10264
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
> Affects Versions: 6.4.2
> Reporter: Jörg Rathlev
> Priority: Minor
> Attachments: SOLR-10264.patch, SOLR-10264.patch, SOLR-10264-test.patch
>
>
> The parser that the {{ManagedSynonymFilterFactory}} uses to parse the JSON
> resource into a synonym map does not parse multi-term synonyms in the
> expected way.
> If the synonym {"foo bar":"baz"} is added to the managed resource, the
> expected behavior is that the multi-term synonym "foo bar" will be mapped to
> the synonym "baz".
> In the {{analyze}} method of {{SynonymMap.Parser}}, multiple origin terms are
> concatenated with a separating {{SynonymMap.WORD_SEPARATOR}}, but the
> {{analyze}} method is not used by the parser in the
> {{ManagedSynonymFilterFactory}}.
> As a workaround, multi-term synonyms can be uploaded separated by a null
> character, i.e., uploading {"foo\u0000bar":"baz"} works.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
