Re: trivia question: why q=*:* doesn't return same result as q.alt=*:*
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 Hostetterwrote: > > : 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=*:*=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=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=*:*
: 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=*:*=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=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=*:*
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 Ericksonwrote: > > 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 > 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=*:*=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=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 >> >> 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==*:*" 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=*:*
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 Iqbalwrote: > 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=*:*=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=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 > > 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==*:*" 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=*:*
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=*:*=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=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 Hostetterwrote: > > : 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==*:*" 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=*:*
: 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==*:*" 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=*:*
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=*:*
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 Hatcherwrote: > defType=??? Probably dismax. It doesn’t do *:* like edismax or lucene. > > > On Jan 4, 2018, at 20:39, Nawab Zada Asad Iqbal > wrote: > > > > Thanks Erik > > Here is the output, > > > > http://localhost:8983/solr/filesearch/select?fq=id:1193; > q.alt=*:*=true > > > > > > - parsedquery: "+MatchAllDocsQuery(*:*)", > > > > > > > > http://localhost:8983/solr/filesearch/select?fq=id:1193; > q=*:*=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=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 > > wrote: > > > >> Hmm, seems odd. What happens when you attach =query? I'm curious > how > >> the parsed queries differ. > >> > >>> On Jan 4, 2018 15:14, "Nawab Zada Asad Iqbal" > 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=*:*
defType=??? Probably dismax. It doesn’t do *:* like edismax or lucene. > On Jan 4, 2018, at 20:39, Nawab Zada Asad Iqbalwrote: > > Thanks Erik > Here is the output, > > http://localhost:8983/solr/filesearch/select?fq=id:1193=*:*=true > > > - parsedquery: "+MatchAllDocsQuery(*:*)", > > > > http://localhost:8983/solr/filesearch/select?fq=id:1193=*:*=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=hello=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 > wrote: > >> Hmm, seems odd. What happens when you attach =query? I'm curious how >> the parsed queries differ. >> >>> On Jan 4, 2018 15:14, "Nawab Zada Asad Iqbal" 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=*:*
Thanks Erik Here is the output, http://localhost:8983/solr/filesearch/select?fq=id:1193=*:*=true - parsedquery: "+MatchAllDocsQuery(*:*)", http://localhost:8983/solr/filesearch/select?fq=id:1193=*:*=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=hello=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 Ericksonwrote: > Hmm, seems odd. What happens when you attach =query? I'm curious how > the parsed queries differ. > > On Jan 4, 2018 15:14, "Nawab Zada Asad Iqbal" 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=*:*
Hmm, seems odd. What happens when you attach =query? I'm curious how the parsed queries differ. On Jan 4, 2018 15:14, "Nawab Zada Asad Iqbal"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=*:*
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