lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-435) QParser must validate existence/absence of "q" parameter
Date Tue, 27 Mar 2012 00:35:28 GMT

     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message