[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238538#comment-13238538
]
Hoss Man commented on SOLR-435:
-------------------------------
bq. If the purpose of the QueryComponent is to be QParser agnostic and
consequently unable to know if the 'q' parameter is even relevant, shouldn't it
be up to the QParser to retrieve what it believes the query string to be from
the request parameters?
Sorry ... i chose my words carelessly and wound up saying almost the exact
opposite of what i ment.
What i should have said...
* QueryComponent is responsible for determining the QParser to use for the main
query and passing it the value of the q query-string param to the
QParser.getParser(...) method
* QParser.getParser passes that query-string on to whater QParserPlugin was
selected as the "qstr" param to the createParser
* The QParser that gets created by the createParser call should do whatever
validation it needs to do (including a null check) in it's parse() method
In answer to your questions...
* QueryComponent can not do any validation of the q param, because it can't
make any assumptions about what the defType QParser this are legal values --
not even a null check, because in case of things like dismax nll is perfectly
fine
* 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
* 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
bq. Hoss: I don't agree with your reasoning on the developer-user typo-ing the
'q' parameter. If you mistype basically any parameter then clearly it is as if
you didn't even specify that parameter and you get the default behavior of the
parameter you were trying to type correctly but didn't.
understood ... but most other situations the "default" behavior is either "do
nothing" or "error" ... we don't have a lot of default behaviors which are
"give me tones of stuff" ... if you use {{facet=true&faceet.field=foo}} (note
the extra character) you don't silently get get faceting on every field as a
default -- you get no field faceting at all. if you misstype the q param name
and get an error on your first attempt you immediately understand you did
something wrong. likewise if we made the default a "matches nothing" query,
then you'd get no results and (hopefully) be suspicious enough to realize you
made a mistake -- but if we give you a bunch of results by default you may not
realize at all that you're looking at all results not just the results of what
you thought the query was. the only situations i can think of where forgetting
or mistyping a param name doens't default to error or nothing are things with
fixed expectations: start, rows, fl, etc... Those have defaults that (if they
don't match what you tried to specify) are immediately obvious ... the 'start'
attribute on the docList returned is wrong, you get more results then you
expected, you get field names you know you didn't specify, etc... it's less
obvious when you are looking at the results of a query that it's a match-all
query instead of the query you thought you were specifying.
like i said ... i'm -0 to having a hardcoded default query for
lucene/dismax/edismax ... if you feel strongly about it that's fine, allthough
i would try to convince you "match none" is a better hardcoded default then
'match all' (so that it's easier to recognize mistakes quickly) and really
don't think we should do it w/o also add q.alt support to the LuceneQParser so
people can override it.
> QParser must validate existance/absense 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: Ryan McKinley
> 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]
