[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238795#comment-13238795
]
David Smiley commented on SOLR-435:
---
If match none were the default, then this would be an additional difference
from a filter query aside from scoring implications. Think about it. If you
don't add any filter queries, in effect there is no filtering, which is kinda
like the default being *:* even though it strictly speaking doesn't work that
way. Shouldn't 'q' work similarly?
I'll commit a better error message later tonight:
{code}
if (qstr == null || qstr.length() == 0)
throw new ParseException("missing query string");
{code}
inside LuceneQParserPlugin.parse(). This is the same error message dismax &
edismax use.
v3.6 is soon and I don't feel like fighting this issue once the error message
is improved.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238560#comment-13238560
]
Ryan McKinley commented on SOLR-435:
bq. if no query string is supplied, or if its blank or just whitespace, then
the default is to match all documents.
-0
When I opened this issue (4 years ago!) I was only worried that you get a NPE
from a missing 'q'
bq. don't think we should do it w/o also add q.alt support to the LuceneQParser
so people can override it.
+1
Match none seems like the most appropriate behavior unless you explicitly say
something else
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
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)
>
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237445#comment-13237445
]
David Smiley commented on SOLR-435:
---
FYI I created an issue for this edismax bug in SOLR-3270 and committed it.
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. In this case, we want
q to be match-all-docs by default. It's not uncommon for there to be no query
-- initial state or just filter queries.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237427#comment-13237427
]
Chris Male commented on SOLR-435:
-
You're absolutely right.
I can see the advantages of having QParser's accept a generic String that they
need to parse, whether it be the main query string or a filter query. But in
that case I don't think QParser's should also be trying to find the query
string themselves in certain cases (such as ExtendedDisMaxQParser trying q.alt
as an alternative source of a query string). QParsers are not required to
respect what the QueryComponent gives them, so you can specify whatever you
like in 'q' or 'fq' and QParser can totally ignore it.
It just feels a little messy and confusing because wherever the query string
identification occurs is where the validation should occur too, right?
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237424#comment-13237424
]
David Smiley commented on SOLR-435:
---
Chris: If you look at QueryComponent a little further down the line it has to
use QParser again to pass in filter queries in 'fq' not 'q'.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237418#comment-13237418
]
Chris Male commented on SOLR-435:
-
{quote}
Chris, as both Hoss and I said, QueryComponent can't assume that the particular
QParser subclass even needs the query string at all, such as when defType=term
or something. Granted that's very unusual but still.
{quote}
That's exactly what I'm saying. The QueryComponent is making that assumption
today. It retrieves a query string from the 'q' param and passes it to the
QParser. Why not let the QParser do this all itself? that way, if the QParser
doesn't need a query string or gets it from somewhere else, it can choose what
to do or what not to do.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237416#comment-13237416
]
David Smiley commented on SOLR-435:
---
IMO the bear minimum change should be a clear error that 'q' is missing. Right
now you get a NullPointerException -- Bad!
Another change that I've always thought should happen that would address this
issue is /search in the example config being configured with defType=edismax
with q.alt=\*:\*
Chris, as both Hoss and I said, QueryComponent can't assume that the particular
QParser subclass even needs the query string at all, such as when defType=term
or something. Granted that's very unusual but still.
Shall I just go ahead and commit the missing trim() bug fix to edismax, or
create an issue for 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237410#comment-13237410
]
Chris Male commented on SOLR-435:
-
{quote}
we definitely shouldn't modify QueryComponent ... the entire point of the issue
is that QueryComponent can't attempt to validate the q param, because it
doesn't know if/when the defType QParser requires it to exist – the individual
QParsers all need to throw clear errors if they require it and it's not
specified, that's really the whole reason this issue was opened in the first
place
{quote}
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? Currently QueryComponent assumes the 'q' parameter value is the
query string, sets that as being the case in the ResponseBuilder and passes it
down to the QParser.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237366#comment-13237366
]
Hoss Man commented on SOLR-435:
---
bq. if no query string is supplied, or if its blank or just whitespace, then
the default is to match all documents.
-0 ... the risk with this approach is that (new) users who make typos in
queries or are missinformed about the name "q" param (ie: {{/search?Q=foo}} or
{{/search?query=foo}}) will be really confused when they query they specify is
completely ignored w/o explanation and all docs are returned in it's place. I
think it's much better to throw a clear error "q param is not specified" but i
certainly see the value in adding q.alt support to the LuceneQParser with the
same semantics as dismax (used if q is missing or all whitespace) .. not sure
why we've never considered that before. (obviosly it wouldn't make sense for
all QParsers, like "field" or "term" since all whitespace and or empty strings
are totally valid input for them)
bq. I could have modified QueryComponent, or just QParser, or just the actual
QParser subclasses. A universal choice couldn't be made for all qparsers...
we definitely shouldn't modify QueryComponent ... the entire point of the issue
is that QueryComponent can't attempt to validate the q param, because it
doesn't know if/when the defType QParser requires it to exist -- the individual
QParsers all need to throw clear errors if they require it and it's not
specified, that's really the whole reason this issue was opened in the first
place
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235020#comment-13235020
]
David Smiley commented on SOLR-435:
---
I've always thought it was bad that Solr throws an error if 'q' is not
specified, and it can be a "WTF" experience to new users unfamiliar with this.
I am aware that dismax has q.alt but that's separate. What's wrong with
assuming a match-all docs query of *:*? It's better than an error, IMO.
FYI aside from seeing this from time to time in my own Solr work, the Ajax-Solr
framework has a work-around to basically automatically supply q or q.alt with
'*:*' in different circumstances, and it's quite a hack. You can argue the
user should explicitly supply *:* but then if they forget, they get a Solr
error.
> 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
> Fix For: 3.6, 4.0
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
