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=dismax&q=foo
is equivalent to
&defType=lucene&q={!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
