[
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: [email protected]
For additional commands, e-mail: [email protected]
