: Of course. What I meant to say was there is
: always exactly one token in a non-tokenized
: field and it's offset is always exactly 0. There
: will never be tokens at position 1.
:
: So asking to match phrases, which is based on
: term positions is basically a no-op.
That's not always true.
c
That was a little confusing!
" there's always exactly one token at position 0."
Of course. What I meant to say was there is
always exactly one token in a non-tokenized
field and it's offset is always exactly 0. There
will never be tokens at position 1.
So asking to match phrases, which is based
A side note: specifying qt and defType on the same query is probably
not what you
intend. I'd just omit the qt bit since you're essentially passing all
the info you intend
explicitly...
I see the same behavior when I specify a non-tokenized field in 3.5
But I don't think this is a bug since it do
I'm observing strange results with both the correct and incorrect behavior
happening depending on which field I put in the 'pf' param. I wouldn't think
this should be analyzer specific, but is it?
If I try:
http://localhost:8080/solr/collection1/select?qt=%2Fsearch&q=mickey%20mouse&debugQuery=on&d
: If I switch back and forth between defType=dismax and defType=edismax, the
: edismax doesn't seem to obey my pf parameter. I dug through the code a
I just tried a sample query using Solr 3.5 with the example configs+data.
This is the query i tried...
http://localhost:8983/solr/select/?debugQu
If I switch back and forth between defType=dismax and defType=edismax, the
edismax doesn't seem to obey my pf parameter. I dug through the code a
little bit and in the ExtendedDismaxQParserPlugin (Solr 3.4/Solr3.5), the
part that is supposed to add the phrase comes here:
Query phrase = pp.parse(us
