lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-435) QParser must validate existence/absence of "q" parameter
Date Mon, 26 Mar 2012 23:36:27 GMT

    [ https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238992#comment-13238992
] 

Chris Male commented on SOLR-435:
---------------------------------

{quote}
QParsers (and QParserPlugins) can't be made responsible for fetching the q param because they
don't know if/when they are being used to parse the main query param, vs fq params, vs some
other nested subquery
{quote}

I agree.  I just have problems with the fact they kind of do this today.  Both DisMaxQParser
and ExtendedDisMaxParser check the q.alt parameter when the string given to them is null.
 So imagine if they're being used to parse a filter query but for whatever reason they are
given a null string so they use the q.alt value instead, even though thats totally unrelated.

{quote}
by putting this kind of validation/error checking in the QParser.parse method, we ensure that
it is used properly even when the QParser(s) are used for things like 'fq' params or in nested
subqueries
{quote}

Again I agree.  But I'm just not sure if that validation / error checking should involve checking
alternative parameters.  That feels like its defeating the goal of QParsers working in all
situations.

I just also wonder whether down the line we want better error messages here too.  David's
suggestion for "missing query string" aligns with other such messages (so I'm all for adding
it).  But I also wonder whether we could do better as well, by having context dependent messages
saying what parameters were missing and how the user can address it.  But that would require
the QParser to know what its being used for which we don't want.  Hence why I think this is
really messy.

I'll leave this discussion here and open another issue at some stage to address this.

{quote}
allthough i would try to convince you "match none" is a better hardcoded default then 'match
all'
{quote}

I agree with Hoss.  If no query was mentioned, nothing was matched.

{quote}
If match none were the default, then this would be an additional difference from a filter
query aside from scoring implications
{quote}

I see them as very different things so I'm not bothered by the difference.
                
> 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_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