Re: defType argument weirdness
: Huh, I'm still not completely following. I'm sure it makes sense if you
: understand the underlying implemetnation, but I don't understand how 'type'
: and 'defType' don't mean exactly the same thing, just need to be expressed
: differently in different location.
...
: prefixing def to type is not making it very clear what the difference is!
: What's def supposed to stand for anyway?)
def == default.
type and defType both select a QParser, but they select the QParser for
parsing different levels of sub queries.
type can only be used as a localparam and it is how you instruct Solr as
to what QParser you want it to use when parsing *that* specific query
string.
defType can be used as either a top level param or as a localparam (to
specify the default value for the type of QParser you want used for
the main query string at that level.
Here's an example i just used last week in a project (isfdb-solr) that
shows what i mean...
q={!boost b=sum(views,annualviews) defType=dismax v=$qq}
...that's just syntactic sugar for...
q={!type=boost b=sum(views,annualviews) defType=dismax v=$qq}
The type localparam (of q) says that the q param should be parsed
using the boost QParser (which is what knows to parse the b param as a
function and how to use it) regardless of whatever top level defType
param might be specified.
the defType localparam then says that when parsing the main sub query
(the qq param in this case) the default value assumed for the type
local param should be dismax.
so if i have this...
q={!boost b=sum(M,N) defType=dismax v=$qq}qq=XXX
that will result in XXX being parsed using the dismax QParser.
...but if i have this...
q={!boost b=sum(M,N) defType=dismax v=$qq}qq={!type=lucene}XXX
...then the defType localparam is ignored and XXX is parsed using the
lucene QParser (type overrides defType).
but defType only applies the default for the main query one level down
... it doesn't recurse forever (and it doesn't apply to secondary query
string parsing like fq or facet.query or the b function in the boost
QParser) so if you have something like this...
q={!boost b=sum(M,N) defType=XXX v=$qq}qq={!lucene v=$zz}zz=CCC
that defType=XXX won't be used when parsing CCC (because it's one level
removed)
-Hoss
Re: defType argument weirdness
On Tue, Jul 19, 2011 at 11:41 PM, Jonathan Rochkind rochk...@jhu.edu wrote:
Is it generally recognized that this terminology is confusing, or is it just
me?
I do understand what they do (at least well enough to use them), but I find
it confusing that it's called defType as a main param, but type in a
LocalParam
When used as the main param, it is still just the default (i.e. it may
be overridden).
For example defType=luceneq={!func}1
(and then there's 'qt', often confused with defType/type by newbies, since
they guess it stands for 'query type', but which should probably actually
have been called 'requestHandler'/'rh' instead, since that's what it actually
chooses, no? It gets very confusing).
Yeah, qt is very historical... before the QParserPlugin framework,
and before request handlers were used for many other things (including
updates).
-Yonik
http://www.lucidimagination.com
If it's generally recognized it's confusing and perhaps a somewhat
inconsistent mental model being implied, I wonder if there'd be any interest
in renaming these to be more clear, leaving the old ones as aliases/synonyms
for backwards compatibility (perhaps with a long deprecation period, or
perhaps existing forever). I know it was very confusing to me to keep track
of these parameters and what they did for quite a while, and still trips me
up from time to time.
Jonathan
From: ysee...@gmail.com [ysee...@gmail.com] on behalf of Yonik Seeley
[yo...@lucidimagination.com]
Sent: Tuesday, July 19, 2011 9:40 PM
To: solr-user@lucene.apache.org
Subject: Re: defType argument weirdness
On Tue, Jul 19, 2011 at 1:25 PM, Naomi Dushay ndus...@stanford.edu wrote:
Regardless, I thought that defType=dismaxq=*:* is supposed to be
equivalent to q={!defType=dismax}*:* and also equivalent to q={!dismax}*:*
Not quite - there is a very subtle distinction.
{!dismax} is short for {!type=dismax}, the type of the actual query,
and this may not be overridden.
The defType local param is only the default type for sub-queries (as
opposed to the current query).
It's useful in conjunction with the query or nested query qparser:
http://lucene.apache.org/solr/api/org/apache/solr/search/NestedQParserPlugin.html
-Yonik
http://www.lucidimagination.com
RE: defType argument weirdness
: I do understand what they do (at least well enough to use them), but I : find it confusing that it's called defType as a main param, but type : in a LocalParam, when to me they both seem to do the same thing -- which type as a localparam in a query string defines the type of query string it is -- picking hte parser. defType determins the default value for type in the primary query string. : (and then there's 'qt', often confused with defType/type by newbies, : since they guess it stands for 'query type', but which should probably : actually have been called 'requestHandler'/'rh' instead, since that's : what it actually chooses, no? It gets very confusing). : : If it's generally recognized it's confusing and perhaps a somewhat : inconsistent mental model being implied, I wonder if there'd be any : interest in renaming these to be more clear, leaving the old ones as : aliases/synonyms for backwards compatibility (perhaps with a long qt is historic and already being de-emphasized in favor of using path based names (ie: http://solr/handlername instead of http://solr/select?qt=/handlername) so adding yet another alias for that would be moving in the wrong direction. type and defType probably make more sense when you think of them in that order. I don't see a strong need to confuse/complicate the issue by adding more aliases for them. -Hoss
Re: defType argument weirdness
Huh, I'm still not completely following. I'm sure it makes sense if you
understand the underlying implemetnation, but I don't understand how
'type' and 'defType' don't mean exactly the same thing, just need to be
expressed differently in different location.
Sorry for beating a dead horse, but maybe it would help if you could
tell me what I'm getting wrong here:
defType can only go in top-level param, and determines the query parser
for the overall q top level param.
type can only go in a LocalParam, and determines the query parser that
applies to whatever query (top-level or nested) that the LocalParam
syntax lives in. (Just as any other LocalParams apply only to the query
that the LocalParam block lives in -- and nested queries inherit their
query parser from the query they are nested in unless over-ridden, just
as they inherit every other param from the query they are nested in
unless over-ridden, nothing special here).
Therefore for instance:
defType=dismaxq=foo
is equivalent to
defType=luceneq={!type=dismax}foo
Where am I straying in my mental model here? Because if all that is
true, I don't understand how 'type' and 'defType' mean anything
different -- they both choose the query parser, do they not? (which to
me means I wish they were both called 'parser' instead of 'type' -- a
'type' here is the name of a query parser, is it not?) It's just that
if it's in the top-level param you have to use 'defType', and if it's in
a LocalParam you have to use 'type'. That's been my mental model, which
has served me well so far, but if it's wrong and it's going to trip me
up on some as yet unencountered use cases, it would probably be good for
me to know it! (And probably good for some documentation to be written
somewhere explaining it too). (And if they really are different,
prefixing def to type is not making it very clear what the
difference is! What's def supposed to stand for anyway?)
Jonathan
On 7/20/2011 3:49 PM, Chris Hostetter wrote:
: I do understand what they do (at least well enough to use them), but I
: find it confusing that it's called defType as a main param, but type
: in a LocalParam, when to me they both seem to do the same thing -- which
type as a localparam in a query string defines the type of query string
it is -- picking hte parser.
defType determins the default value for type in the primary query
string.
: (and then there's 'qt', often confused with defType/type by newbies,
: since they guess it stands for 'query type', but which should probably
: actually have been called 'requestHandler'/'rh' instead, since that's
: what it actually chooses, no? It gets very confusing).
:
: If it's generally recognized it's confusing and perhaps a somewhat
: inconsistent mental model being implied, I wonder if there'd be any
: interest in renaming these to be more clear, leaving the old ones as
: aliases/synonyms for backwards compatibility (perhaps with a long
qt is historic and already being de-emphasized in favor of using
path based names (ie: http://solr/handlername instead of
http://solr/select?qt=/handlername) so adding yet another alias for that
would be moving in the wrong direction.
type and defType probably make more sense when you think of
them in that order. I don't see a strong need to confuse/complicate the
issue by adding more aliases for them.
-Hoss
Re: defType argument weirdness
On Jul 18, 2011, at 19:15 , Naomi Dushay wrote:
I found a weird behavior with the Solr defType argument, perhaps with
respect to default queries?
q={!defType=dismax}*:* hits
this is the confusing one. defType is a Solr request parameter, but not
something that works as a local (inside the {!} brackets) parameter.
Confusing, indeed. But just not how local params/defType works at the moment.
So, with defType being ignored in those curly brackets, you're getting the
default lucene query parser. Check it out with debugQuery=true and see how
queries parse.
Erik
Re: defType argument weirdness
qf_dismax and pf_dismax are irrelevant -- I shouldn't have included
that info. They are passed in the url and they work; they do not
affect this problem.
Your reminder of debugQuery was a good one - I use that a lot but
forgot in this case.
Regardless, I thought that defType=dismaxq=*:* is supposed to
be equivalent to q={!defType=dismax}*:* and also equivalent to q={!
dismax}*:*
defType=dismaxq=*:* DOESN'T WORK
str name=rawquerystring*:*/str
str name=querystring*:*/str
str name=parsedquery+() ()/str
str name=parsedquery_toString+() ()/str
leaving out the explicit query
defType=dismax WORKS
null name=rawquerystring/
null name=querystring/
str name=parsedquery+MatchAllDocsQuery(*:*)/str
str name=parsedquery_toString+*:*/str
q={!dismax}*:* DOESN'T WORK
str name=rawquerystring*:*/str
str name=querystring*:*/str
str name=parsedquery+() ()/str
str name=parsedquery_toString+() ()/str
leaving out the explicit query:
q={!dismax}WORKS
str name=rawquerystring{!dismax}/str
str name=querystring{!dismax}/str
str name=parsedquery+MatchAllDocsQuery(*:*)/str
str name=parsedquery_toString+*:*/str
q={!defType=dismax}*:*WORKS
str name=rawquerystring{!defType=dismax}*:*/str
str name=querystring{!defType=dismax}*:*/str
str name=parsedqueryMatchAllDocsQuery(*:*)/str
str name=parsedquery_toString*:*/str
leaving out the explicit query:
q={!defType=dismax}DOESN'T WORK
org.apache.lucene.queryParser.ParseException: Cannot parse '':
Encountered EOF at line 1, column 0.
On Jul 18, 2011, at 5:44 PM, Erick Erickson wrote:
What are qf_dismax and pf_dismax? They are meaningless to
Solr. Try adding debugQuery=on to your URL and you'll
see the parsed query, which helps a lot here
If you change these to the proper dismax values (qf and pf)
you'll get beter results. As it is, I think you'll see output like:
str name=parsedquery+() ()/str
showing that your query isn't actually going against
any fields
Best
Erick
On Mon, Jul 18, 2011 at 7:15 PM, Naomi Dushay ndus...@stanford.edu
wrote:
I found a weird behavior with the Solr defType argument, perhaps
with
respect to default queries?
defType=dismaxq=*:* no hits
q={!defType=dismax}*:* hits
defType=dismax hits
Here is the request handler, which I explicitly indicate:
requestHandler name=search class=solr.SearchHandler
default=true
lst name=defaults
str name=defTypelucene/str
!-- lucene params --
str name=dfhas_model_s/str
str name=q.opAND/str
!-- dismax params --
str name=mm 2-1 5-2 690% /str
str name=q.alt*:*/str
str name=qf_dismaxid^0.8 id_t^0.8 title_t^0.3
mods_t^0.2
text/str
str name=pf_dismaxid^0.9 id_t^0.9 title_t^0.5
mods_t^0.2
text/str
int name=ps100/int
float name=tie0.01/float
/requestHandler
Solr Specification Version: 1.4.0
Solr Implementation Version: 1.4.0 833479 - grantingersoll -
2009-11-06
12:33:40
Lucene Specification Version: 2.9.1
Lucene Implementation Version: 2.9.1 832363 - 2009-11-03 04:37:25
- Naomi
Re: defType argument weirdness
On Tue, Jul 19, 2011 at 1:25 PM, Naomi Dushay ndus...@stanford.edu wrote:
Regardless, I thought that defType=dismaxq=*:* is supposed to be
equivalent to q={!defType=dismax}*:* and also equivalent to q={!dismax}*:*
Not quite - there is a very subtle distinction.
{!dismax} is short for {!type=dismax}, the type of the actual query,
and this may not be overridden.
The defType local param is only the default type for sub-queries (as
opposed to the current query).
It's useful in conjunction with the query or nested query qparser:
http://lucene.apache.org/solr/api/org/apache/solr/search/NestedQParserPlugin.html
-Yonik
http://www.lucidimagination.com
RE: defType argument weirdness
Is it generally recognized that this terminology is confusing, or is it just
me?
I do understand what they do (at least well enough to use them), but I find it
confusing that it's called defType as a main param, but type in a
LocalParam, when to me they both seem to do the same thing -- which I think
should probably be called 'queryParser' rather than 'type' or 'defType'.
That's what they do, choose the query parser for the query they apply to,
right? (And if they did/do different things, 'defType' vs 'type' doesn't
really provide much hint as to what!)
These are both the same, right, but with different param names depending on
position:
defType=luceneq=foo
q={!type=lucene}foo # uri escaping not shown
(and then there's 'qt', often confused with defType/type by newbies, since they
guess it stands for 'query type', but which should probably actually have been
called 'requestHandler'/'rh' instead, since that's what it actually chooses,
no? It gets very confusing).
If it's generally recognized it's confusing and perhaps a somewhat inconsistent
mental model being implied, I wonder if there'd be any interest in renaming
these to be more clear, leaving the old ones as aliases/synonyms for backwards
compatibility (perhaps with a long deprecation period, or perhaps existing
forever). I know it was very confusing to me to keep track of these parameters
and what they did for quite a while, and still trips me up from time to time.
Jonathan
From: ysee...@gmail.com [ysee...@gmail.com] on behalf of Yonik Seeley
[yo...@lucidimagination.com]
Sent: Tuesday, July 19, 2011 9:40 PM
To: solr-user@lucene.apache.org
Subject: Re: defType argument weirdness
On Tue, Jul 19, 2011 at 1:25 PM, Naomi Dushay ndus...@stanford.edu wrote:
Regardless, I thought that defType=dismaxq=*:* is supposed to be
equivalent to q={!defType=dismax}*:* and also equivalent to q={!dismax}*:*
Not quite - there is a very subtle distinction.
{!dismax} is short for {!type=dismax}, the type of the actual query,
and this may not be overridden.
The defType local param is only the default type for sub-queries (as
opposed to the current query).
It's useful in conjunction with the query or nested query qparser:
http://lucene.apache.org/solr/api/org/apache/solr/search/NestedQParserPlugin.html
-Yonik
http://www.lucidimagination.com
defType argument weirdness
I found a weird behavior with the Solr defType argument, perhaps with
respect to default queries?
defType=dismaxq=*:* no hits
q={!defType=dismax}*:* hits
defType=dismax hits
Here is the request handler, which I explicitly indicate:
requestHandler name=search class=solr.SearchHandler default=true
lst name=defaults
str name=defTypelucene/str
!-- lucene params --
str name=dfhas_model_s/str
str name=q.opAND/str
!-- dismax params --
str name=mm 2-1 5-2 690% /str
str name=q.alt*:*/str
str name=qf_dismaxid^0.8 id_t^0.8 title_t^0.3 mods_t^0.2 text/
str
str name=pf_dismaxid^0.9 id_t^0.9 title_t^0.5 mods_t^0.2 text/
str
int name=ps100/int
float name=tie0.01/float
/requestHandler
Solr Specification Version: 1.4.0
Solr Implementation Version: 1.4.0 833479 - grantingersoll -
2009-11-06 12:33:40
Lucene Specification Version: 2.9.1
Lucene Implementation Version: 2.9.1 832363 - 2009-11-03 04:37:25
- Naomi
Re: defType argument weirdness
What are qf_dismax and pf_dismax? They are meaningless to
Solr. Try adding debugQuery=on to your URL and you'll
see the parsed query, which helps a lot here
If you change these to the proper dismax values (qf and pf)
you'll get beter results. As it is, I think you'll see output like:
str name=parsedquery+() ()/str
showing that your query isn't actually going against
any fields
Best
Erick
On Mon, Jul 18, 2011 at 7:15 PM, Naomi Dushay ndus...@stanford.edu wrote:
I found a weird behavior with the Solr defType argument, perhaps with
respect to default queries?
defType=dismaxq=*:* no hits
q={!defType=dismax}*:* hits
defType=dismax hits
Here is the request handler, which I explicitly indicate:
requestHandler name=search class=solr.SearchHandler default=true
lst name=defaults
str name=defTypelucene/str
!-- lucene params --
str name=dfhas_model_s/str
str name=q.opAND/str
!-- dismax params --
str name=mm 2-1 5-2 690% /str
str name=q.alt*:*/str
str name=qf_dismaxid^0.8 id_t^0.8 title_t^0.3 mods_t^0.2
text/str
str name=pf_dismaxid^0.9 id_t^0.9 title_t^0.5 mods_t^0.2
text/str
int name=ps100/int
float name=tie0.01/float
/requestHandler
Solr Specification Version: 1.4.0
Solr Implementation Version: 1.4.0 833479 - grantingersoll - 2009-11-06
12:33:40
Lucene Specification Version: 2.9.1
Lucene Implementation Version: 2.9.1 832363 - 2009-11-03 04:37:25
- Naomi
Re: defType argument weirdness
dismax does not work with a=*:*
defType=dismaxq=*:* no hits
You need to switch this to:
defType=dismaxq.alt=*:* no hits
On Mon, Jul 18, 2011 at 8:44 PM, Erick Erickson erickerick...@gmail.com wrote:
What are qf_dismax and pf_dismax? They are meaningless to
Solr. Try adding debugQuery=on to your URL and you'll
see the parsed query, which helps a lot here
If you change these to the proper dismax values (qf and pf)
you'll get beter results. As it is, I think you'll see output like:
str name=parsedquery+() ()/str
showing that your query isn't actually going against
any fields
Best
Erick
On Mon, Jul 18, 2011 at 7:15 PM, Naomi Dushay ndus...@stanford.edu wrote:
I found a weird behavior with the Solr defType argument, perhaps with
respect to default queries?
defType=dismaxq=*:* no hits
q={!defType=dismax}*:* hits
defType=dismax hits
Here is the request handler, which I explicitly indicate:
requestHandler name=search class=solr.SearchHandler default=true
lst name=defaults
str name=defTypelucene/str
!-- lucene params --
str name=dfhas_model_s/str
str name=q.opAND/str
!-- dismax params --
str name=mm 2-1 5-2 690% /str
str name=q.alt*:*/str
str name=qf_dismaxid^0.8 id_t^0.8 title_t^0.3 mods_t^0.2
text/str
str name=pf_dismaxid^0.9 id_t^0.9 title_t^0.5 mods_t^0.2
text/str
int name=ps100/int
float name=tie0.01/float
/requestHandler
Solr Specification Version: 1.4.0
Solr Implementation Version: 1.4.0 833479 - grantingersoll - 2009-11-06
12:33:40
Lucene Specification Version: 2.9.1
Lucene Implementation Version: 2.9.1 832363 - 2009-11-03 04:37:25
- Naomi
--
Bill Bell
billnb...@gmail.com
cell 720-256-8076
