[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-435:
--------------------------
Attachment: SOLR-435.patch
bq. It doesn't really do that though. Take DisMaxQParser for example, if it
can't find a query string through either its given string or through the q.alt
param, it throws a SolrException
Sorry ... i was looking at my patched version -- agreed it should throw
ParseException
bq. At best the QueryComponent catches a ParseException but since it wraps both
the parsing of the main query and filter queries into the same try-catch block,
it just wraps the ParseException in a SolrException and throws it. Again, no
context.
...that can be fixed though, it doesn't cahnge the question of semantics for
the QParsers themselves
---
Here's the patch i put together, the attempted goal was:
1) add javadocs to QParser.parse documenting the (current) expectations
2) automated test verifying that al built-in QParsers meet the expectations
when given null or empty string
3) standardizes lucene, dismax, and edismax to treat empty query strings as
valid representations of matching nothing
4) fixes all the other special case QParsers to throw a ParseError on null or
empty string based on what makes sense (ie: things like TermQParser should
allow "" as input, but things like FunctionQParser should not)
...however the test is currently broken, because it doesn't account for the
fact that some of the special case QParsers have other required params -- it
does however nicely demonstrate other ways these Qparsers do a bad job of
reporting errors.
Given te level of debate in this issue, and the differences in opinion on what
the right / wrong way to address this broader topic of query parsing validation
i suggest we punt on this for Solr 3.6 -- I'd rather leave things the way they
are then make a bad decision in a hurry
> QParser must validate existence/absence of "q" parameter
> --------------------------------------------------------
>
> Key: SOLR-435
> URL: https://issues.apache.org/jira/browse/SOLR-435
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 1.3
> Reporter: Ryan McKinley
> Assignee: David Smiley
> Fix For: 3.6, 4.0
>
> Attachments: SOLR-435.patch, SOLR-435_q_defaults_to_all-docs.patch
>
>
> Each QParser should check if "q" exists or not. For some it will be required
> others not.
> currently it throws a null pointer:
> {code}
> java.lang.NullPointerException
> at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:36)
> at
> org.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java:104)
> at org.apache.solr.search.QParser.getQuery(QParser.java:80)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:67)
> at
> org.apache.solr.handler.SearchHandler.handleRequestBody(SearchHandler.java:150)
> ...
> {code}
> see:
> http://www.nabble.com/query-parsing-error-to14124285.html#a14140108
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.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]
