discrepancy between LuceneQParser and ExtendedDismaxQParser
Hello,
Found discrepancy between LuceneQParser and ExtendedDismaxQParser when
executing following query:
((*:* AND -area) OR area:[100 TO 300]) AND objectId:40105451
When executing it through Solr Admin panel and placing query in "q" field I
having following debug output for LuceneQParser
--
"debug": {
"rawquerystring": "((*:* AND -area) OR area:[100 TO 300]) AND
objectId:40105451",
"querystring": "((*:* AND -area) OR area:[100 TO 300]) AND
objectId:40105451",
"parsedquery": "+((+MatchAllDocsQuery(*:*) -text:area) area:[100 TO 300])
+objectId:40105451",
"parsedquery_toString": "+((+*:* -text:area) area:[100 TO 300]) +objectId:
\u0001\u\u\u\u\u\u0013\u000fkk",
"explain": {
"40105451": "\n14.3511 = (MATCH) sum of:\n 0.034590416 = (MATCH) product
of:\n0.06918083 = (MATCH) sum of:\n 0.06918083 = (MATCH) sum of:\n
0.06918083 = (MATCH) MatchAllDocsQuery, product of:\n 0.06918083 =
queryNorm\n0.5 = coord(1/2)\n 14.316509 = (MATCH) weight(objectId:
\u0001\u\u\u\u\u\u0013\u000fkk in 1109978)
[DefaultSimilarity], result of:\n14.316509 = score(doc=1109978,freq=1.0),
product of:\n 0.9952025 = queryWeight, product of:\n14.385524 =
idf(docFreq=1, maxDocs=1301035)\n0.06918083 = queryNorm\n
14.385524 = fieldWeight in 1109978, product of:\n1.0 = tf(freq=1.0),
with freq of:\n 1.0 = termFreq=1.0\n14.385524 = idf(docFreq=1,
maxDocs=1301035)\n1.0 = fieldNorm(doc=1109978)\n"
},
--
So, one object found which is expectable
For ExtendedDismaxQParser (only difference is checkbox "edismax" checked) I am
seeing this output
--
"debug": {
"rawquerystring": "((*:* AND -area) OR area:[100 TO 300]) AND
objectId:40105451",
"querystring": "((*:* AND -area) OR area:[100 TO 300]) AND
objectId:40105451",
"parsedquery": "(+(+((+DisjunctionMaxQuery((text:*\\:*))
-DisjunctionMaxQuery((text:area))) area:[100 TO 300])
+objectId:40105451))/no_coord",
"parsedquery_toString": "+(+((+(text:*\\:*) -(text:area)) area:[100 TO
300]) +objectId: \u0001\u\u\u\u\u\u0013\u000fkk)",
"explain": {},
--
oops, no objects found!
I hastened to fill https://issues.apache.org/jira/browse/SOLR-7249 (sorry, my
bad)
You may refer to it for additional info (not going to duplicate it here)
Thanks
--
Best regards,
Arsen mailto:barracuda...@mail.ru
Re[2]: discrepancy between LuceneQParser and ExtendedDismaxQParser
Hello Jack,
Jack, you made "my day" for me.
Indeed, when I inserted space between "(" and "*:*" sings - issue
disappeared. I believe, that according to debug - "space" bug forced
both parsers to treat part in first brackets as text, right?
It looks like https://issues.apache.org/jira/browse/SOLR-7249 can be
closed (root cause is another bug). Let me know if anything more
needed from my side (should I add comment to it?).
> There was a Solr release with a bug that required that you put a space
> between the left parenthesis and the "*:*". The edismax parsed query here
> indicates that the "*:*" has not parsed properly.
> You have "area", but in your jira you had a range query.
You are right, I played with your suggestions about "area" parameter,
was running different variations of it, but they all give same result.
So, I left most recent variant (which was shorter, sorry).
Thanks again for your help!
Have a nice day.
> -- Jack Krupansky
> On Mon, Mar 16, 2015 at 6:42 PM, Arsen wrote:
>> Hello,
>>
>> Found discrepancy between LuceneQParser and ExtendedDismaxQParser when
>> executing following query:
>> ((*:* AND -area) OR area:[100 TO 300]) AND objectId:40105451
>>
>> When executing it through Solr Admin panel and placing query in "q" field
>> I having following debug output for LuceneQParser
>> --
>> "debug": {
>> "rawquerystring": "((*:* AND -area) OR area:[100 TO 300]) AND
>> objectId:40105451",
>> "querystring": "((*:* AND -area) OR area:[100 TO 300]) AND
>> objectId:40105451",
>> "parsedquery": "+((+MatchAllDocsQuery(*:*) -text:area) area:[100 TO
>> 300]) +objectId:40105451",
>> "parsedquery_toString": "+((+*:* -text:area) area:[100 TO 300])
>> +objectId: \u0001\u\u\u\u\u\u0013\u000fkk",
>> "explain": {
>> "40105451": "\n14.3511 = (MATCH) sum of:\n 0.034590416 = (MATCH)
>> product of:\n0.06918083 = (MATCH) sum of:\n 0.06918083 = (MATCH)
>> sum of:\n0.06918083 = (MATCH) MatchAllDocsQuery, product of:\n
>> 0.06918083 = queryNorm\n0.5 = coord(1/2)\n 14.316509 = (MATCH)
>> weight(objectId: \u0001\u\u\u\u\u\u0013\u000fkk in
>> 1109978) [DefaultSimilarity], result of:\n14.316509 =
>> score(doc=1109978,freq=1.0), product of:\n 0.9952025 = queryWeight,
>> product of:\n14.385524 = idf(docFreq=1, maxDocs=1301035)\n
>> 0.06918083 = queryNorm\n 14.385524 = fieldWeight in 1109978, product
>> of:\n1.0 = tf(freq=1.0), with freq of:\n 1.0 =
>> termFreq=1.0\n14.385524 = idf(docFreq=1, maxDocs=1301035)\n
>> 1.0 = fieldNorm(doc=1109978)\n"
>> },
>> --
>> So, one object found which is expectable
>>
>> For ExtendedDismaxQParser (only difference is checkbox "edismax" checked)
>> I am seeing this output
>> --
>> "debug": {
>> "rawquerystring": "((*:* AND -area) OR area:[100 TO 300]) AND
>> objectId:40105451",
>> "querystring": "((*:* AND -area) OR area:[100 TO 300]) AND
>> objectId:40105451",
>> "parsedquery": "(+(+((+DisjunctionMaxQuery((text:*\\:*))
>> -DisjunctionMaxQuery((text:area))) area:[100 TO 300])
>> +objectId:40105451))/no_coord",
>> "parsedquery_toString": "+(+((+(text:*\\:*) -(text:area)) area:[100 TO
>> 300]) +objectId: \u0001\u\u\u\u\u\u0013\u000fkk)",
>> "explain": {},
>> --
>> oops, no objects found!
>>
>> I hastened to fill https://issues.apache.org/jira/browse/SOLR-7249
>> (sorry, my bad)
>> You may refer to it for additional info (not going to duplicate it here)
>>
>> Thanks
>>
>> --
>> Best regards,
>> Arsen mailto:barracuda...@mail.ru
>>
>>
--
Best regards,
Arsenmailto:barracuda...@mail.ru
Re[4]: discrepancy between LuceneQParser and ExtendedDismaxQParser
Hello Jack,
4.10.3 as already indicated in https://issues.apache.org/jira/browse/SOLR-7249
> Great, glad to hear it!
> One last question: What release of Solr are you using?
> -- Jack Krupansky
> On Tue, Mar 17, 2015 at 11:43 AM, Arsen wrote:
>> Hello Jack,
>>
>> Jack, you made "my day" for me.
>>
>> Indeed, when I inserted space between "(" and "*:*" sings - issue
>> disappeared. I believe, that according to debug - "space" bug forced
>> both parsers to treat part in first brackets as text, right?
>>
>> It looks like https://issues.apache.org/jira/browse/SOLR-7249 can be
>> closed (root cause is another bug). Let me know if anything more
>> needed from my side (should I add comment to it?).
>>
>> > There was a Solr release with a bug that required that you put a space
>> > between the left parenthesis and the "*:*". The edismax parsed query here
>> > indicates that the "*:*" has not parsed properly.
>>
>> > You have "area", but in your jira you had a range query.
>>
>> You are right, I played with your suggestions about "area" parameter,
>> was running different variations of it, but they all give same result.
>> So, I left most recent variant (which was shorter, sorry).
>>
>> Thanks again for your help!
>> Have a nice day.
>>
>> > -- Jack Krupansky
>>
>> > On Mon, Mar 16, 2015 at 6:42 PM, Arsen wrote:
>>
--
Best regards,
Arsenmailto:barracuda...@mail.ru
