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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Nawab Zada Asad Iqbal
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
Reply | Threaded
Open this post in threaded view
|

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

Erick Erickson
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" <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

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

Nawab Zada Asad Iqbal
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 <[hidden email]>
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" <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

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

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

> On Jan 4, 2018, at 20:39, Nawab Zada Asad Iqbal <[hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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
>>>
>>
Reply | Threaded
Open this post in threaded view
|

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

Nawab Zada Asad Iqbal
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 <[hidden email]> wrote:

> defType=???  Probably dismax.  It doesn’t do *:* like edismax or lucene.
>
> > On Jan 4, 2018, at 20:39, Nawab Zada Asad Iqbal <[hidden email]>
> 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 <[hidden email]>
> > 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" <[hidden email]>
> 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
> >>>
> >>
>
Reply | Threaded
Open this post in threaded view
|

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

Shawn Heisey-2
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
Reply | Threaded
Open this post in threaded view
|

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

Chris Hostetter-3
In reply to this post by Nawab Zada Asad Iqbal

: 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/
Reply | Threaded
Open this post in threaded view
|

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

Nawab Zada Asad Iqbal
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 <[hidden email]>
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/
>
Reply | Threaded
Open this post in threaded view
|

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

Erick Erickson
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 <[hidden email]>
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 <[hidden email]
> >
> 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/
> >
>
Reply | Threaded
Open this post in threaded view
|

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

Erik Hatcher-4
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
>>>
>> 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/
>>>
>>
Reply | Threaded
Open this post in threaded view
|

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

Chris Hostetter-3

: 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/
Reply | Threaded
Open this post in threaded view
|

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

Nawab Zada Asad Iqbal
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 <[hidden email]>
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/
>