[jira] [Commented] (SOLR-3740) ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized sub-queries
[
https://issues.apache.org/jira/browse/SOLR-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471280#comment-13471280
]
Michael Krkoska commented on SOLR-3740:
---
I ran into this issue with a simple query like ID100, which gets rewritten by
a WordDelimiterFilter in my config into (text:ID text:100). Unfortunately my
q.op=AND is not passed on to the underlying query parser, which results in a
OR, as that's the default.
Adding
{code:java}
up.setDefaultOperator(QueryParsing.getQueryParserDefaultOperator(req.getSchema(),
solrParams.get(QueryParsing.OP)));
{code}
in line 193 of ExtendedDismaxQParserPlugin fixes the bug for me and seems
sensible.
Please look into this before 4.0 release, as it seems to be a rather serious
bug.
ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized
sub-queries
Key: SOLR-3740
URL: https://issues.apache.org/jira/browse/SOLR-3740
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 3.6.1, 4.0-BETA
Reporter: Jack Krupansky
For a query such as cat dog (fox bat fish) with q.op=AND, the default
query operator is only set to AND for the top-level query, and not for the
parenthesize sub-query. This is not documented behavior and rather surprising.
This happens because edismax only simulates the default operator by forcing
mm (minMatch) to 100% for the top-level BooleanQuery alone and never sets
the default query operator when it invokes the classic Lucene Query parser
which in turn is performing parsing and query generation for the
parenthesized sub-query.
One solution is for edismax to always set the default query operator when
calling the classic Lucene query parser, or at least when q.op=AND.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3740) ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized sub-queries
[ https://issues.apache.org/jira/browse/SOLR-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471290#comment-13471290 ] Michael Krkoska commented on SOLR-3740: --- bq. In this specific case, you may want autoGeneratePhraseQueries=true set on your field type so that any split tokens end up acting like a phrase query of ID 100. Thanks, that's indeed useful! But while it is a workaround for some cases of the bug, I still see the issue as something serious. ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized sub-queries Key: SOLR-3740 URL: https://issues.apache.org/jira/browse/SOLR-3740 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 3.6.1, 4.0-BETA Reporter: Jack Krupansky For a query such as cat dog (fox bat fish) with q.op=AND, the default query operator is only set to AND for the top-level query, and not for the parenthesize sub-query. This is not documented behavior and rather surprising. This happens because edismax only simulates the default operator by forcing mm (minMatch) to 100% for the top-level BooleanQuery alone and never sets the default query operator when it invokes the classic Lucene Query parser which in turn is performing parsing and query generation for the parenthesized sub-query. One solution is for edismax to always set the default query operator when calling the classic Lucene query parser, or at least when q.op=AND. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-573) Escaped quotes inside a phrase cause a ParseException
[ http://issues.apache.org/jira/browse/LUCENE-573?page=comments#action_12443214 ] Michael Krkoska commented on LUCENE-573: I just experienced this bug in my search. The patch works for me, though I found it rather cumbersome to build lucene including javacc. Why is the priority of this bug low? What do we have to do to include tha patch in the release? Escaped quotes inside a phrase cause a ParseException - Key: LUCENE-573 URL: http://issues.apache.org/jira/browse/LUCENE-573 Project: Lucene - Java Issue Type: Bug Components: QueryParser Affects Versions: 1.9 Environment: Debian Sarge, Sun JDK 1.4.2 Reporter: Tomislav Gountchev Priority: Minor Attachments: escaped_quotes_inside_phrases.patch QueryParser cannot handle escaped quotes when inside a phrase. Escaped quotes not in a phrase are not a problem. This can be added to TestQueryParser.testEscaped() to demonstrate the issue - the second assert throws an exception: assertQueryEquals(a \\\b c\\\ d, a, a \b c\ d); assertQueryEquals(\a \\\b c\\\ d\, a, \a \b c\ d\); See also this thread: http://www.nabble.com/ParseException-with-escaped-quotes-in-a-phrase-t1647115.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
