You are viewing a plain text version of this content. The canonical link for it is here.

Posted to solr-user@lucene.apache.org by Nawab Zada Asad Iqbal <kh...@gmail.com> on 2018/01/04 23:14:28 UTC

trivia question: why q=: doesn't return same result as q.alt=:

Hi,

In my SearchHandler solrconfig, i have q.alt=*:* . This allows me to run
queries which only have `fq` filters and no `q`.

If I remove q.alt from the solrconfig and specify `q=*:*` in the query
parameters, it does not give any results. I also tried `q=*` but of no
avail.

Is there some good reason for this behavior? Since I already know a work
around, this question is only for my curiosity.


Thanks
Nawab

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Shawn Heisey <ap...@elyograg.org>.

On 1/5/2018 7:22 PM, Nawab Zada Asad Iqbal wrote:
> Yes, i am using dismax. But dismax allows *:* for q.alt ,which also seems
> like inconsistency.

It works in q.alt because q.alt is interpreted using the standard 
(lucene) query parser.

The dismax parser doesn't understand lucene syntax like *:* ... but *:* 
is typically the most common setting for q.alt, so Solr can't use dismax 
to interpret the q.alt query.

The edismax parser does understand *:* -- and it should be a superset of 
dismax functionality.  You MIGHT be able to use edismax instead of 
dismax without any changes.

Thanks,
Shawn

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Nawab Zada Asad Iqbal <kh...@gmail.com>.

Chris / Hoss

Thanks for the detailed explanation. Erick Erickson's explanation made
sense to me but it didn't explain the part why the fields are different for
'hello' vs '*:*' .

I had never paid much attention the parser part of query handling and so
far focused only on the field definitions. I had to re-read parts of this
thread to understand the whole picture.

I had dropped an apparently unnecessary question but this thread has
provided a lot of necessary learning.


Thanks
Nawab

On Fri, Jan 12, 2018 at 10:38 AM, Chris Hostetter <ho...@fucit.org>
wrote:

>
> : defType=dismax does NOT do anything special with *:* other than treat it
>         ...
> : > As Chris explained, this is special:
>         ...
>
> I'm interpreting your followup question differently then Erick & Erik
> did.  I'm going to assume both E & E missunderstood your question, and i'm
> going to assume you completley understood my response to your original
> question.
>
> I'm going to assume that a way to rewrod/expand your followup question is
> something like this...
>
> "I understand now that defType=dismax doesn't support special syntax like
> '*:*' and treats that 3 input as just another 3 character string to search
> against the qf & pf fields -- but now what i don't understand is why are
> list of fields in the debug query output is different for 'q=*:*' compared
> to something like 'q=hello'"
>
> (If i have not understood your followup question correctly, please
> clarify)
>
> Let's look at those outputs you mentioned...
>
> : >> http://localhost:8983/solr/filesearch/select?fq=id:1193&
> : >> q=*:*&debugQuery=true
> : >>
> : >>
> : >>   - parsedquery: "+DisjunctionMaxQuery((user_email:*:* |
> user_name:*:* |
> : >>   tags:*:* | (name_shingle_zh-cn:, , name_shingle_zh-cn:, ,) |
> : >> id:*:*)~0.01)
> : >>   DisjunctionMaxQuery(((name_shingle_zh-cn:", , , ,"~100)^100.0 |
> : >>   tags:*:*)~0.01)",
> ...
> : >> e.g. following query uses the my expected set of pf and qf.
> ...
> : >> http://localhost:8983/solr/filesearch/select?fq=id:1193&
> : >> q=hello&debugQuery=true
> : >>
> : >>
> : >>
> : >>   - parsedquery: "+DisjunctionMaxQuery(((name_token:hello)^60.0 |
> : >>   user_email:hello | (name_combined:hello)^10.0 |
> (name_zh-cn:hello)^10.0
> : >> |
> : >>   name_shingle:hello | comments:hello | user_name:hello |
> : >> description:hello |
> : >>   file_content_zh-cn:hello | file_content_de:hello | tags:hello |
> : >>   file_content_it:hell | file_content_fr:hello | file_content_es:hell
> |
> : >>   file_content_en:hello | id:hello)~0.01)
> : >> DisjunctionMaxQuery((description:hello
> : >>   | (name_shingle:hello)^100.0 | comments:hello | tags:hello)~0.01)",
>
>
> The answer has to do with the list of qf & pf fields you have confiugred
> -- you didn't provide us with concrete specifics of what qf/pf you
> have configured in your requestHandler -- but you did mention in your
> second example that "following query uses the my expected set of pf and
> qf"
>
> By comparing the 2 examples at a glance, It appears that the fields in the
> first example (q=*:* ... again, searching for the literal 3 character
> string '*:*') are (mostly) a subset of the fields you "expected" (from the
> 2nd example)
>
> I'm fairly certain that what's happening here is that in both examples the
> literal string input is being given to the analyzer for all of your fields
> -- but in the case of the (literal) string '*:*' many of the analyzers are
> producing no terms at all -- ie: they are completley striping out
> punctuation -- so they don't appear in the final query.
>
> IIUC it looks like one other oddity here is that the reverse also
> seems to be true in some cases -- i suspect that
> although "name_shingle_zh-cn" doesn't appera in your 2nd example, it
> probably *is* in your pf param but whatever analyzer you have confiured
> for it produces no tokens for the latin characters "hello" but does
> produces tokens for the pure-punctuation characters "*:*"
>
>
> (If i'm correct about your question, but wrong about your qf/pf then
> please provide us with a lot more details -- notably your full
> schema/solrconfig used when executing those queries.
>
>
> -Hoss
> http://www.lucidworks.com/
>

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Chris Hostetter <ho...@fucit.org>.

: defType=dismax does NOT do anything special with *:* other than treat it 
	...
: > As Chris explained, this is special:
	...

I'm interpreting your followup question differently then Erick & Erik 
did.  I'm going to assume both E & E missunderstood your question, and i'm 
going to assume you completley understood my response to your original 
question.

I'm going to assume that a way to rewrod/expand your followup question is 
something like this...

"I understand now that defType=dismax doesn't support special syntax like 
'*:*' and treats that 3 input as just another 3 character string to search 
against the qf & pf fields -- but now what i don't understand is why are 
list of fields in the debug query output is different for 'q=*:*' compared 
to something like 'q=hello'"

(If i have not understood your followup question correctly, please 
clarify)

Let's look at those outputs you mentioned...

: >> http://localhost:8983/solr/filesearch/select?fq=id:1193&
: >> q=*:*&debugQuery=true
: >> 
: >> 
: >>   - parsedquery: "+DisjunctionMaxQuery((user_email:*:* | user_name:*:* |
: >>   tags:*:* | (name_shingle_zh-cn:, , name_shingle_zh-cn:, ,) |
: >> id:*:*)~0.01)
: >>   DisjunctionMaxQuery(((name_shingle_zh-cn:", , , ,"~100)^100.0 |
: >>   tags:*:*)~0.01)",
...
: >> e.g. following query uses the my expected set of pf and qf.
...
: >> http://localhost:8983/solr/filesearch/select?fq=id:1193&
: >> q=hello&debugQuery=true
: >> 
: >> 
: >> 
: >>   - parsedquery: "+DisjunctionMaxQuery(((name_token:hello)^60.0 |
: >>   user_email:hello | (name_combined:hello)^10.0 | (name_zh-cn:hello)^10.0
: >> |
: >>   name_shingle:hello | comments:hello | user_name:hello |
: >> description:hello |
: >>   file_content_zh-cn:hello | file_content_de:hello | tags:hello |
: >>   file_content_it:hell | file_content_fr:hello | file_content_es:hell |
: >>   file_content_en:hello | id:hello)~0.01)
: >> DisjunctionMaxQuery((description:hello
: >>   | (name_shingle:hello)^100.0 | comments:hello | tags:hello)~0.01)",


The answer has to do with the list of qf & pf fields you have confiugred 
-- you didn't provide us with concrete specifics of what qf/pf you 
have configured in your requestHandler -- but you did mention in your 
second example that "following query uses the my expected set of pf and 
qf"

By comparing the 2 examples at a glance, It appears that the fields in the 
first example (q=*:* ... again, searching for the literal 3 character 
string '*:*') are (mostly) a subset of the fields you "expected" (from the 
2nd example)

I'm fairly certain that what's happening here is that in both examples the 
literal string input is being given to the analyzer for all of your fields 
-- but in the case of the (literal) string '*:*' many of the analyzers are 
producing no terms at all -- ie: they are completley striping out 
punctuation -- so they don't appear in the final query.

IIUC it looks like one other oddity here is that the reverse also 
seems to be true in some cases -- i suspect that 
although "name_shingle_zh-cn" doesn't appera in your 2nd example, it 
probably *is* in your pf param but whatever analyzer you have confiured 
for it produces no tokens for the latin characters "hello" but does 
produces tokens for the pure-punctuation characters "*:*"


(If i'm correct about your question, but wrong about your qf/pf then 
please provide us with a lot more details -- notably your full 
schema/solrconfig used when executing those queries.


-Hoss
http://www.lucidworks.com/

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Erik Hatcher <er...@gmail.com>.

I think what Erick meant to say ;) was ....

defType=dismax does NOT do anything special with *:* other than treat it as plain text and does dismaxy things with it.   That’s exactly why there is q.alt for the dismax parser - so you can have your dismax and still match all docs by not having a q. 
 
   Erik

> On Jan 6, 2018, at 22:48, Erick Erickson <er...@gmail.com> wrote:
> 
> As Chris explained, this is special:
> q=*:*
> in terms of scoring or anything of the like. It's just match-all-docs
> 
> It makes no sense to distribute *:* among "pf" fields. The whole point
> of pf is to influence scoring by providing a mechanism for boosting
> when words in some field(s) appear together for docs that _already_
> match the main clause. The fp fields may be totally
> unrelated to the qf fields. There's no reason to couple those together.
> 
> pf means "for docs that match the main query, add an additional boost
> if there are phrase matches in these fields". Whether the pf fields match
> a document has no influence on whether that doc is a hit, it only changes
> the score of docs that have been selected anyway because they matched
> the main clause.
> 
> Another way of saying the above is numFound won't change at all no
> matter whether there are matches on "pf" fields or not. Only the scores
> of those docs might change.
> 
> Since q=hello isn't match-all-docs, it does make sense to boost by "pf"
> field matches, even though it's just a single word. In that case it really
> means "boost docs matching the main clause if this word appears in
> the pf field".
> 
> On a different note, field names with hyphens aren't necessarily supported,
> so "name_shingle_zh-cn" may work, but there also may be edge cases
> where that causes problems. If there are, it's unlikely that fixing them
> will
> be a priority.
> 
> From the ref guide:
> 
> "The name of the field. Field names should consist of alphanumeric or
> underscore characters only and not start with a digit."
> 
> There has been talk at times of throwing warnings or errors if names violate
> this, but that'd break existing apps. It's one of those things that's we
> live
> with ;)
> 
> Best,
> Erick
> 
> On Sat, Jan 6, 2018 at 6:13 PM, Nawab Zada Asad Iqbal <kh...@gmail.com>
> wrote:
> 
>> Thanks everyone, that was a very informative thread.
>> 
>> One more curiosity: why are different set of fields being used based on the
>> query string:-
>> 
>> 
>> http://localhost:8983/solr/filesearch/select?fq=id:1193&
>> q=*:*&debugQuery=true
>> 
>> 
>>   - parsedquery: "+DisjunctionMaxQuery((user_email:*:* | user_name:*:* |
>>   tags:*:* | (name_shingle_zh-cn:, , name_shingle_zh-cn:, ,) |
>> id:*:*)~0.01)
>>   DisjunctionMaxQuery(((name_shingle_zh-cn:", , , ,"~100)^100.0 |
>>   tags:*:*)~0.01)",
>> 
>> 
>> 
>> I find it perplexing as the default values for qf and pf are very different
>> from above so I am not sure where these fields are coming from (although
>> they are all valid fields)
>> e.g. following query uses the my expected set of pf and qf.
>> 
>> http://localhost:8983/solr/filesearch/select?fq=id:1193&
>> q=hello&debugQuery=true
>> 
>> 
>> 
>>   - parsedquery: "+DisjunctionMaxQuery(((name_token:hello)^60.0 |
>>   user_email:hello | (name_combined:hello)^10.0 | (name_zh-cn:hello)^10.0
>> |
>>   name_shingle:hello | comments:hello | user_name:hello |
>> description:hello |
>>   file_content_zh-cn:hello | file_content_de:hello | tags:hello |
>>   file_content_it:hell | file_content_fr:hello | file_content_es:hell |
>>   file_content_en:hello | id:hello)~0.01)
>> DisjunctionMaxQuery((description:hello
>>   | (name_shingle:hello)^100.0 | comments:hello | tags:hello)~0.01)",
>> 
>> 
>> On Sat, Jan 6, 2018 at 12:05 PM, Chris Hostetter <hossman_lucene@fucit.org
>>> 
>> wrote:
>> 
>>> 
>>> : Yes, i am using dismax. But dismax allows *:* for q.alt ,which also
>> seems
>>> : like inconsistency.
>>> 
>>> dismax is a *parser* that affects how a single query string is parsed.
>>> 
>>> when you use defType=dismax, that only changes how the "q" param is
>>> parsed -- not any other query string params, like "fq" or "facet.query"
>>> (or "q.alt")
>>> 
>>> when you have a request like "defType=dismax&q=&q.alt=*:*" what you are
>>> saying, and what solr is doing, is...
>>> 
>>> * YOU: hey solr, use dismax as the default parser for the q param
>>> * SEARCHHANDLER: ok, if the "q" param does not use local params to
>>> override the parser, i will use dismax
>>> * SEARCHHANDLER: hey dismax qparser, go parse the string ""
>>> * DISMAXQP: that string is empty, so instead we should use q.alt
>>> * SEARCHHANDLER: ok, i will parse the q.alt param and use that query in
>>> place of the empty q param
>>> * SEARCHHANDLER: hey lucene qparser, the string "*:*" does not use local
>>> params to override the parser, please parse it
>>> * LUCENEQP: the string "*:*" is a MatchAllDocsQuery
>>> * SEARCHHANDLER: cool, i'll use that as my main query
>>> 
>>> 
>>> 
>>> -Hoss
>>> http://www.lucidworks.com/
>>> 
>>

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Erick Erickson <er...@gmail.com>.

As Chris explained, this is special:
q=*:*
in terms of scoring or anything of the like. It's just match-all-docs

It makes no sense to distribute *:* among "pf" fields. The whole point
of pf is to influence scoring by providing a mechanism for boosting
when words in some field(s) appear together for docs that _already_
match the main clause. The fp fields may be totally
unrelated to the qf fields. There's no reason to couple those together.

pf means "for docs that match the main query, add an additional boost
if there are phrase matches in these fields". Whether the pf fields match
a document has no influence on whether that doc is a hit, it only changes
the score of docs that have been selected anyway because they matched
the main clause.

Another way of saying the above is numFound won't change at all no
matter whether there are matches on "pf" fields or not. Only the scores
of those docs might change.

Since q=hello isn't match-all-docs, it does make sense to boost by "pf"
field matches, even though it's just a single word. In that case it really
means "boost docs matching the main clause if this word appears in
the pf field".

On a different note, field names with hyphens aren't necessarily supported,
so "name_shingle_zh-cn" may work, but there also may be edge cases
where that causes problems. If there are, it's unlikely that fixing them
will
be a priority.

From the ref guide:

"The name of the field. Field names should consist of alphanumeric or
underscore characters only and not start with a digit."

There has been talk at times of throwing warnings or errors if names violate
this, but that'd break existing apps. It's one of those things that's we
live
with ;)

Best,
Erick

On Sat, Jan 6, 2018 at 6:13 PM, Nawab Zada Asad Iqbal <kh...@gmail.com>
wrote:

> Thanks everyone, that was a very informative thread.
>
> One more curiosity: why are different set of fields being used based on the
> query string:-
>
>
> http://localhost:8983/solr/filesearch/select?fq=id:1193&
> q=*:*&debugQuery=true
>
>
>    - parsedquery: "+DisjunctionMaxQuery((user_email:*:* | user_name:*:* |
>    tags:*:* | (name_shingle_zh-cn:, , name_shingle_zh-cn:, ,) |
> id:*:*)~0.01)
>    DisjunctionMaxQuery(((name_shingle_zh-cn:", , , ,"~100)^100.0 |
>    tags:*:*)~0.01)",
>
>
>
> I find it perplexing as the default values for qf and pf are very different
> from above so I am not sure where these fields are coming from (although
> they are all valid fields)
> e.g. following query uses the my expected set of pf and qf.
>
> http://localhost:8983/solr/filesearch/select?fq=id:1193&
> q=hello&debugQuery=true
>
>
>
>    - parsedquery: "+DisjunctionMaxQuery(((name_token:hello)^60.0 |
>    user_email:hello | (name_combined:hello)^10.0 | (name_zh-cn:hello)^10.0
> |
>    name_shingle:hello | comments:hello | user_name:hello |
> description:hello |
>    file_content_zh-cn:hello | file_content_de:hello | tags:hello |
>    file_content_it:hell | file_content_fr:hello | file_content_es:hell |
>    file_content_en:hello | id:hello)~0.01)
> DisjunctionMaxQuery((description:hello
>    | (name_shingle:hello)^100.0 | comments:hello | tags:hello)~0.01)",
>
>
> On Sat, Jan 6, 2018 at 12:05 PM, Chris Hostetter <hossman_lucene@fucit.org
> >
> wrote:
>
> >
> > : Yes, i am using dismax. But dismax allows *:* for q.alt ,which also
> seems
> > : like inconsistency.
> >
> > dismax is a *parser* that affects how a single query string is parsed.
> >
> > when you use defType=dismax, that only changes how the "q" param is
> > parsed -- not any other query string params, like "fq" or "facet.query"
> > (or "q.alt")
> >
> > when you have a request like "defType=dismax&q=&q.alt=*:*" what you are
> > saying, and what solr is doing, is...
> >
> > * YOU: hey solr, use dismax as the default parser for the q param
> > * SEARCHHANDLER: ok, if the "q" param does not use local params to
> > override the parser, i will use dismax
> > * SEARCHHANDLER: hey dismax qparser, go parse the string ""
> > * DISMAXQP: that string is empty, so instead we should use q.alt
> > * SEARCHHANDLER: ok, i will parse the q.alt param and use that query in
> > place of the empty q param
> > * SEARCHHANDLER: hey lucene qparser, the string "*:*" does not use local
> > params to override the parser, please parse it
> > * LUCENEQP: the string "*:*" is a MatchAllDocsQuery
> > * SEARCHHANDLER: cool, i'll use that as my main query
> >
> >
> >
> > -Hoss
> > http://www.lucidworks.com/
> >
>

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Nawab Zada Asad Iqbal <kh...@gmail.com>.

Thanks everyone, that was a very informative thread.

One more curiosity: why are different set of fields being used based on the
query string:-


http://localhost:8983/solr/filesearch/select?fq=id:1193&
q=*:*&debugQuery=true


   - parsedquery: "+DisjunctionMaxQuery((user_email:*:* | user_name:*:* |
   tags:*:* | (name_shingle_zh-cn:, , name_shingle_zh-cn:, ,) | id:*:*)~0.01)
   DisjunctionMaxQuery(((name_shingle_zh-cn:", , , ,"~100)^100.0 |
   tags:*:*)~0.01)",



I find it perplexing as the default values for qf and pf are very different
from above so I am not sure where these fields are coming from (although
they are all valid fields)
e.g. following query uses the my expected set of pf and qf.

http://localhost:8983/solr/filesearch/select?fq=id:1193&
q=hello&debugQuery=true



   - parsedquery: "+DisjunctionMaxQuery(((name_token:hello)^60.0 |
   user_email:hello | (name_combined:hello)^10.0 | (name_zh-cn:hello)^10.0 |
   name_shingle:hello | comments:hello | user_name:hello | description:hello |
   file_content_zh-cn:hello | file_content_de:hello | tags:hello |
   file_content_it:hell | file_content_fr:hello | file_content_es:hell |
   file_content_en:hello | id:hello)~0.01)
DisjunctionMaxQuery((description:hello
   | (name_shingle:hello)^100.0 | comments:hello | tags:hello)~0.01)",


On Sat, Jan 6, 2018 at 12:05 PM, Chris Hostetter <ho...@fucit.org>
wrote:

>
> : Yes, i am using dismax. But dismax allows *:* for q.alt ,which also seems
> : like inconsistency.
>
> dismax is a *parser* that affects how a single query string is parsed.
>
> when you use defType=dismax, that only changes how the "q" param is
> parsed -- not any other query string params, like "fq" or "facet.query"
> (or "q.alt")
>
> when you have a request like "defType=dismax&q=&q.alt=*:*" what you are
> saying, and what solr is doing, is...
>
> * YOU: hey solr, use dismax as the default parser for the q param
> * SEARCHHANDLER: ok, if the "q" param does not use local params to
> override the parser, i will use dismax
> * SEARCHHANDLER: hey dismax qparser, go parse the string ""
> * DISMAXQP: that string is empty, so instead we should use q.alt
> * SEARCHHANDLER: ok, i will parse the q.alt param and use that query in
> place of the empty q param
> * SEARCHHANDLER: hey lucene qparser, the string "*:*" does not use local
> params to override the parser, please parse it
> * LUCENEQP: the string "*:*" is a MatchAllDocsQuery
> * SEARCHHANDLER: cool, i'll use that as my main query
>
>
>
> -Hoss
> http://www.lucidworks.com/
>

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Chris Hostetter <ho...@fucit.org>.

: Yes, i am using dismax. But dismax allows *:* for q.alt ,which also seems
: like inconsistency.

dismax is a *parser* that affects how a single query string is parsed.

when you use defType=dismax, that only changes how the "q" param is 
parsed -- not any other query string params, like "fq" or "facet.query" 
(or "q.alt")

when you have a request like "defType=dismax&q=&q.alt=*:*" what you are 
saying, and what solr is doing, is...

* YOU: hey solr, use dismax as the default parser for the q param
* SEARCHHANDLER: ok, if the "q" param does not use local params to 
override the parser, i will use dismax
* SEARCHHANDLER: hey dismax qparser, go parse the string ""
* DISMAXQP: that string is empty, so instead we should use q.alt
* SEARCHHANDLER: ok, i will parse the q.alt param and use that query in 
place of the empty q param
* SEARCHHANDLER: hey lucene qparser, the string "*:*" does not use local 
params to override the parser, please parse it
* LUCENEQP: the string "*:*" is a MatchAllDocsQuery
* SEARCHHANDLER: cool, i'll use that as my main query



-Hoss
http://www.lucidworks.com/

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Nawab Zada Asad Iqbal <kh...@gmail.com>.

HI Erik Hatcher

Yes, i am using dismax. But dismax allows *:* for q.alt ,which also seems
like inconsistency.

On Thu, Jan 4, 2018 at 5:53 PM, Erik Hatcher <er...@gmail.com> wrote:

> defType=???  Probably dismax.  It doesn’t do *:* like edismax or lucene.
>
> > On Jan 4, 2018, at 20:39, Nawab Zada Asad Iqbal <kh...@gmail.com>
> wrote:
> >
> > Thanks Erik
> > Here is the output,
> >
> > http://localhost:8983/solr/filesearch/select?fq=id:1193&
> q.alt=*:*&debugQuery=true
> >
> >
> >   - parsedquery: "+MatchAllDocsQuery(*:*)",
> >
> >
> >
> > http://localhost:8983/solr/filesearch/select?fq=id:1193&
> q=*:*&debugQuery=true
> >
> >
> >   - parsedquery: "+DisjunctionMaxQuery((user_email:*:* | user_name:*:* |
> >   tags:*:* | (name_shingle_zh-cn:, , name_shingle_zh-cn:, ,) |
> id:*:*)~0.01)
> >   DisjunctionMaxQuery(((name_shingle_zh-cn:", , , ,"~100)^100.0 |
> >   tags:*:*)~0.01)",
> >
> >
> >
> > I find it perplexing as the default values for qf and pf are very
> different
> > from above so I am not sure where these fields are coming from (although
> > they are all valid fields)
> > e.g. following query uses the my expected set of pf and qf.
> >
> > http://localhost:8983/solr/filesearch/select?fq=id:1193&
> q=hello&debugQuery=true
> >
> >
> >
> >   - parsedquery: "+DisjunctionMaxQuery(((name_token:hello)^60.0 |
> >   user_email:hello | (name_combined:hello)^10.0 |
> (name_zh-cn:hello)^10.0 |
> >   name_shingle:hello | comments:hello | user_name:hello |
> description:hello |
> >   file_content_zh-cn:hello | file_content_de:hello | tags:hello |
> >   file_content_it:hell | file_content_fr:hello | file_content_es:hell |
> >   file_content_en:hello | id:hello)~0.01)
> >   DisjunctionMaxQuery((description:hello | (name_shingle:hello)^100.0 |
> >   comments:hello | tags:hello)~0.01)",
> >
> >
> >
> >
> >
> > On Thu, Jan 4, 2018 at 5:22 PM, Erick Erickson <er...@gmail.com>
> > wrote:
> >
> >> Hmm, seems odd. What happens when you attach &debug=query? I'm curious
> how
> >> the parsed queries differ.
> >>
> >>> On Jan 4, 2018 15:14, "Nawab Zada Asad Iqbal" <kh...@gmail.com>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> In my SearchHandler solrconfig, i have q.alt=*:* . This allows me to
> run
> >>> queries which only have `fq` filters and no `q`.
> >>>
> >>> If I remove q.alt from the solrconfig and specify `q=*:*` in the query
> >>> parameters, it does not give any results. I also tried `q=*` but of no
> >>> avail.
> >>>
> >>> Is there some good reason for this behavior? Since I already know a
> work
> >>> around, this question is only for my curiosity.
> >>>
> >>>
> >>> Thanks
> >>> Nawab
> >>>
> >>
>

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Erik Hatcher <er...@gmail.com>.

defType=???  Probably dismax.  It doesn’t do *:* like edismax or lucene.  

> On Jan 4, 2018, at 20:39, Nawab Zada Asad Iqbal <kh...@gmail.com> wrote:
> 
> Thanks Erik
> Here is the output,
> 
> http://localhost:8983/solr/filesearch/select?fq=id:1193&q.alt=*:*&debugQuery=true
> 
> 
>   - parsedquery: "+MatchAllDocsQuery(*:*)",
> 
> 
> 
> http://localhost:8983/solr/filesearch/select?fq=id:1193&q=*:*&debugQuery=true
> 
> 
>   - parsedquery: "+DisjunctionMaxQuery((user_email:*:* | user_name:*:* |
>   tags:*:* | (name_shingle_zh-cn:, , name_shingle_zh-cn:, ,) | id:*:*)~0.01)
>   DisjunctionMaxQuery(((name_shingle_zh-cn:", , , ,"~100)^100.0 |
>   tags:*:*)~0.01)",
> 
> 
> 
> I find it perplexing as the default values for qf and pf are very different
> from above so I am not sure where these fields are coming from (although
> they are all valid fields)
> e.g. following query uses the my expected set of pf and qf.
> 
> http://localhost:8983/solr/filesearch/select?fq=id:1193&q=hello&debugQuery=true
> 
> 
> 
>   - parsedquery: "+DisjunctionMaxQuery(((name_token:hello)^60.0 |
>   user_email:hello | (name_combined:hello)^10.0 | (name_zh-cn:hello)^10.0 |
>   name_shingle:hello | comments:hello | user_name:hello | description:hello |
>   file_content_zh-cn:hello | file_content_de:hello | tags:hello |
>   file_content_it:hell | file_content_fr:hello | file_content_es:hell |
>   file_content_en:hello | id:hello)~0.01)
>   DisjunctionMaxQuery((description:hello | (name_shingle:hello)^100.0 |
>   comments:hello | tags:hello)~0.01)",
> 
> 
> 
> 
> 
> On Thu, Jan 4, 2018 at 5:22 PM, Erick Erickson <er...@gmail.com>
> wrote:
> 
>> Hmm, seems odd. What happens when you attach &debug=query? I'm curious how
>> the parsed queries differ.
>> 
>>> On Jan 4, 2018 15:14, "Nawab Zada Asad Iqbal" <kh...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> In my SearchHandler solrconfig, i have q.alt=*:* . This allows me to run
>>> queries which only have `fq` filters and no `q`.
>>> 
>>> If I remove q.alt from the solrconfig and specify `q=*:*` in the query
>>> parameters, it does not give any results. I also tried `q=*` but of no
>>> avail.
>>> 
>>> Is there some good reason for this behavior? Since I already know a work
>>> around, this question is only for my curiosity.
>>> 
>>> 
>>> Thanks
>>> Nawab
>>> 
>>

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Nawab Zada Asad Iqbal <kh...@gmail.com>.

Thanks Erik
Here is the output,

http://localhost:8983/solr/filesearch/select?fq=id:1193&q.alt=*:*&debugQuery=true


   - parsedquery: "+MatchAllDocsQuery(*:*)",



http://localhost:8983/solr/filesearch/select?fq=id:1193&q=*:*&debugQuery=true


   - parsedquery: "+DisjunctionMaxQuery((user_email:*:* | user_name:*:* |
   tags:*:* | (name_shingle_zh-cn:, , name_shingle_zh-cn:, ,) | id:*:*)~0.01)
   DisjunctionMaxQuery(((name_shingle_zh-cn:", , , ,"~100)^100.0 |
   tags:*:*)~0.01)",



I find it perplexing as the default values for qf and pf are very different
from above so I am not sure where these fields are coming from (although
they are all valid fields)
e.g. following query uses the my expected set of pf and qf.

http://localhost:8983/solr/filesearch/select?fq=id:1193&q=hello&debugQuery=true



   - parsedquery: "+DisjunctionMaxQuery(((name_token:hello)^60.0 |
   user_email:hello | (name_combined:hello)^10.0 | (name_zh-cn:hello)^10.0 |
   name_shingle:hello | comments:hello | user_name:hello | description:hello |
   file_content_zh-cn:hello | file_content_de:hello | tags:hello |
   file_content_it:hell | file_content_fr:hello | file_content_es:hell |
   file_content_en:hello | id:hello)~0.01)
   DisjunctionMaxQuery((description:hello | (name_shingle:hello)^100.0 |
   comments:hello | tags:hello)~0.01)",





On Thu, Jan 4, 2018 at 5:22 PM, Erick Erickson <er...@gmail.com>
wrote:

> Hmm, seems odd. What happens when you attach &debug=query? I'm curious how
> the parsed queries differ.
>
> On Jan 4, 2018 15:14, "Nawab Zada Asad Iqbal" <kh...@gmail.com> wrote:
>
> > Hi,
> >
> > In my SearchHandler solrconfig, i have q.alt=*:* . This allows me to run
> > queries which only have `fq` filters and no `q`.
> >
> > If I remove q.alt from the solrconfig and specify `q=*:*` in the query
> > parameters, it does not give any results. I also tried `q=*` but of no
> > avail.
> >
> > Is there some good reason for this behavior? Since I already know a work
> > around, this question is only for my curiosity.
> >
> >
> > Thanks
> > Nawab
> >
>

Re: trivia question: why q=: doesn't return same result as q.alt=:

Posted by Erick Erickson <er...@gmail.com>.

Hmm, seems odd. What happens when you attach &debug=query? I'm curious how
the parsed queries differ.

On Jan 4, 2018 15:14, "Nawab Zada Asad Iqbal" <kh...@gmail.com> wrote:

> Hi,
>
> In my SearchHandler solrconfig, i have q.alt=*:* . This allows me to run
> queries which only have `fq` filters and no `q`.
>
> If I remove q.alt from the solrconfig and specify `q=*:*` in the query
> parameters, it does not give any results. I also tried `q=*` but of no
> avail.
>
> Is there some good reason for this behavior? Since I already know a work
> around, this question is only for my curiosity.
>
>
> Thanks
> Nawab
>

trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*

trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=:

Re: trivia question: why q=: doesn't return same result as q.alt=: