lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-435) QParser must validate existence/absence of "q" parameter
Date Tue, 27 Mar 2012 00:19:27 GMT


Chris Male commented on SOLR-435:

Not sure i see the problem, ... part of the advantage in how q.alt it's implemented now is
that you can put things like...

Yeah that is a cool way to to use q.alt.  But that is only usable when a q.alt is specified
in the local params of the QParser.  We don't prevent users from specifying it as a normal
param, and then the QParser can be looking up a parameter that is not intended to be for it.
 For safety, shouldn't we constrain such parameters to being local params only?

It wouldn't have to ... parse() can throw ParseExceptions and QueryCOmponent (or whatever
delegated to the QParser can wrap that in a user error (QueryCOmponent already does that)

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
which isn't caught by QueryComponent.  So there isn't any context here except through the
stack trace.  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.
> QParser must validate existence/absence of "q" parameter
> --------------------------------------------------------
>                 Key: SOLR-435
>                 URL:
>             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_q_defaults_to_all-docs.patch
> Each QParser should check if "q" exists or not.  For some it will be required others
> currently it throws a null pointer:
> {code}
> java.lang.NullPointerException
> 	at org.apache.solr.common.util.StrUtils.splitSmart(
> 	at
> 	at
> 	at org.apache.solr.handler.component.QueryComponent.prepare(
> 	at org.apache.solr.handler.SearchHandler.handleRequestBody(
>         ...
> {code}
> see:

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message