[ https://issues.apache.org/jira/browse/SOLR-12243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16456929#comment-16456929 ]
Elizabeth Haubert edited comment on SOLR-12243 at 4/27/18 7:26 PM: ------------------------------------------------------------------- The fix I pushed up really only handles the case where you're starting with the single-word synonym well for pf2. So matching "foo bar" queries to "foo tropical cyclone" documents. This was a real problem for my use case, because the pf clauses weren't being generated at all. The other direction, to match "foo tropical cyclone" queries to "foo bar" documents is harder. I've gone a little ways into the pf2 "b tropical" problem, but it is a deeper problem than the spans getting thrown out because they were the wrong type of query. Start small. Here's what I've got for the other direction: One of first thing edismax does is generate a list of different kinds of clauses off the user query, and that seems to be unaffected by the sow flag. So "foo tropical cyclone" has three bareword clauses: "foo", "tropical", and "cyclone". But 'foo "tropical cyclone"' (with quotes) has two: a bareword foo and a phrase "tropical cyclone". When it goes to construct pf2 and pf3, edismax re-assembles the bareword clauses, then makes the 2- and 3- word shingles. So "foo tropical cyclone" would get pf2="foo tropical" and "tropical cyclone", pf2="foo tropical" can't get expanded, because it is missing cyclone, and will go through such as it is; "tropical cyclone" will get expanded, but then removed as not a phrase, not just because it is a Span. That seems consistent if we think of "tropical cyclone" as a single entity. So to do anything, we need to address how the shingle queries are being constructed. I opened Jira-12260 to start looping in the phrases to pf clauses, not just the barewords, because that has some other weird semantics. So 'foo "tropical cyclone" baz' (with quotes) would generate pf="foo baz", which is unintuitive - it would make more sense if it became "foo "tropical cyclone"" and "tropical cyclone" baz. Beyond looking a little into whether the graph queries could handle the phrase, I haven't really dug how to do that yet. That matters here, because if that works and the semantics are acceptable, multi-word synoynms are already handled as quoted in the logic that creates the graph queries. So it would (probably) be safe to take that another step to stuff the multiword synonyms into a single phrase clause, rather than individual bareword clauses. Maybe. was (Author: ehaubert): The fix I pushed up really only handles the case where you're starting with the single-word synonym well. So matching "foo bar" queries to "foo tropical cyclone" documents. This was a real problem for my use case, because the pf clauses weren't being generated at all. The other direction, to match "foo tropical cyclone" queries to "foo bar" documents is harder. I've gone a little ways into the pf2 "b tropical" problem, but it is a deeper problem than the spans getting thrown out because they were the wrong type of query. Start small. Here's what I've got for the other direction: One of first thing edismax does is generate a list of different kinds of clauses off the user query, and that seems to be unaffected by the sow flag. So "foo tropical cyclone" has three bareword clauses: "foo", "tropical", and "cyclone". But 'foo "tropical cyclone"' (with quotes) has two: a bareword foo and a phrase "tropical cyclone". When it goes to construct pf2 and pf3, edismax re-assembles the bareword clauses, then makes the 2- and 3- word shingles. So "foo tropical cyclone" would get pf2="foo tropical" and "tropical cyclone", pf2="foo tropical" can't get expanded, because it is missing cyclone, and will go through such as it is; "tropical cyclone" will get expanded, but then removed as not a phrase, not just because it is a Span. That seems consistent if we think of "tropical cyclone" as a single entity. So to do anything, we need to address how the shingle queries are being constructed. I opened Jira-12260 to start looping in the phrases to pf clauses, not just the barewords, because that has some other weird semantics. So 'foo "tropical cyclone" baz' (with quotes) would generate pf="foo baz", which is unintuitive - it would make more sense if it became "foo "tropical cyclone"" and "tropical cyclone" baz. Beyond looking a little into whether the graph queries could handle the phrase, I haven't really dug how to do that yet. That matters here, because if that works and the semantics are acceptable, multi-word synoynms are already handled as quoted in the logic that creates the graph queries. So it would (probably) be safe to take that another step to stuff the multiword synonyms into a single phrase clause, rather than individual bareword clauses. Maybe. > Edismax missing phrase queries when phrases contain multiterm synonyms > ---------------------------------------------------------------------- > > Key: SOLR-12243 > URL: https://issues.apache.org/jira/browse/SOLR-12243 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers > Affects Versions: 7.1 > Environment: RHEL, MacOS X > Do not believe this is environment-specific. > Reporter: Elizabeth Haubert > Priority: Major > Attachments: SOLR-12243.patch > > > synonyms.txt: > allergic, hypersensitive > aspirin, acetylsalicylic acid > dog, canine, canis familiris, k 9 > rat, rattus > request handler: > <requestHandler name="/test_qparse_error" class="solr.SearchHandler"> > <lst name="defaults"> > <!-- Query settings --> > <str name="defType">edismax</str> > <str name="tie"> 0.4</str> > <str name="qf">title^100</str> > <str name="pf">title~20^5000</str> > <str name="pf2">title~11</str> > <str name="pf3">title~22^1000</str> > <str name="df">text</str> > <!-- mm If two or fewer clauses exist, they all must match. > If three to five clauses exist, one can be missing. If six to eight clauses > exist, all but three must match. > If more than nine clauses exist, only require 30% to match.--> > <str name="mm">3<-1 6<-3 9<30%</str> > <str name="q.alt">*:*</str> > <str name="rows">25</str> > </lst> > </requestHandler> > Phrase queries (pf, pf2, pf3) containing "dog" or "aspirin" against the > above list will not be generated. > "allergic reaction dog" will generate pf2: "allergic reaction", but not > pf:"allergic reaction dog", pf2: "reaction dog", or pf3: "allergic reaction > dog" > "aspirin dose in rats" will generate pf3: "dose ? rats" but not pf2: "aspirin > dose" or pf3:"aspirin dose ?" > -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org