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 Hongtai Xue <hx...@yahoo-corp.jp> on 2020/03/02 09:45:35 UTC
strange behavior of solr query parser
Hi,
Our team found a strange behavior of solr query parser.
In some specific cases, some conditional clauses on unindexed field will be ignored.
for query like, q=A:1 OR B:1 OR A:2 OR B:2
if field B is not indexed(but docValues="true"), "B:1" will be lost.
but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
it will work perfect.
the only difference of two queries is that they are wrote in different orders.
one is ABAB, another is AABB,
■reproduce steps and example explanation
you can easily reproduce this problem on a solr collection with _default configset and exampledocs/books.csv data.
1. create a _default collection
bin/solr create -c books -s 2 -rf 2
2. post books.csv.
bin/post -c books example/exampledocs/books.csv
3. run following query.
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+cat%3Abook+OR+name_str%3AJhereg+OR+cat%3Acd%29&debug=query
I printed query parsing debug information.
you can tell "name_str:Foundation" is lost.
query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
(please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75 6e 64 61 74 69 6f 6e")
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])",
"QParser":"LuceneQParser"}}
--------
but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd",
everything is OK. "name_str:Foundation" is not lost.
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])))",
"parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"QParser":"LuceneQParser"}}
--------
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+name_str%3AJhereg+OR+cat%3Abook+OR+cat%3Acd%29&debug=query
we did a little bit research, and we wander if it is a bug of SolrQueryParser.
more specifically, we think if statement here might be wrong.
https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
Could you please tell us if it is a bug, or it's just a wrong query statement.
Thanks,
Hongtai Xue
Re: strange behavior of solr query parser
Posted by Hongtai Xue <hx...@yahoo-corp.jp>.
Hi Phil.Staley
Thanks for your reply.
but I'm afraid that's a different problem.
Our problem can be confirmed since at least SOLR 7.3.0. (the oldest version we have)
And we guess it might already exists since SOLR-9786.
https://github.com/apache/lucene-solr/commit/bf9db95f218f49bac8e7971eb953a9fd9d13a2f0#diff-269ae02e56283ced3ce781cce21b3147R563
sincerely
hongtai
送信元: "Staley, Phil R - DCF" <Ph...@wisconsin.gov>
Reply-To: "dev@lucene.apache.org" <de...@lucene.apache.org>
日付: 2020年3月2日 月曜日 22:38
宛先: solr_user lucene_apache <so...@lucene.apache.org>, "dev@lucene.apache.org" <de...@lucene.apache.org>
件名: Re: strange behavior of solr query parser
I believe we are experiencing the same thing.
We recently upgraded to our Drupal 8 sites to SOLR 8.3.1. We are now getting reports of certain patterns of search terms resulting in an error that reads, “The website encountered an unexpected error. Please try again later.”
Below is a list of example terms that always result in this error and a similar list that works fine. The problem pattern seems to be a search term that contains 2 or 3 characters followed by a space, followed by additional text.
To confirm that the problem is version 8 of SOLR, I have updated our local and UAT sites with the latest Drupal updates that did include an update to the Search API Solr module and tested the terms below under SOLR 7.7.2, 8.3.1, and 8.4.1. Under version 7.7.2 everything works fine. Under either of the version 8, the problem returns.
Thoughts?
Search terms that result in error
• w-2 agency directory
• agency w-2 directory
• w-2 agency
• w-2 directory
• w2 agency directory
• w2 agency
• w2 directory
Search terms that do not result in error
• w-22 agency directory
• agency directory w-2
• agency w-2directory
• agencyw-2 directory
• w-2
• w2
• agency directory
• agency
• directory
• -2 agency directory
• 2 agency directory
• w-2agency directory
• w2agency directory
From: Hongtai Xue <hx...@yahoo-corp.jp>
Sent: Monday, March 2, 2020 3:45 AM
To: solr_user lucene_apache <so...@lucene.apache.org>
Cc: dev@lucene.apache.org <de...@lucene.apache.org>
Subject: strange behavior of solr query parser
Hi,
Our team found a strange behavior of solr query parser.
In some specific cases, some conditional clauses on unindexed field will be ignored.
for query like, q=A:1 OR B:1 OR A:2 OR B:2
if field B is not indexed(but docValues="true"), "B:1" will be lost.
but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
it will work perfect.
the only difference of two queries is that they are wrote in different orders.
one is ABAB, another is AABB,
■reproduce steps and example explanation
you can easily reproduce this problem on a solr collection with _default configset and exampledocs/books.csv data.
1. create a _default collection
bin/solr create -c books -s 2 -rf 2
2. post books.csv.
bin/post -c books example/exampledocs/books.csv
3. run following query.
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+cat%3Abook+OR+name_str%3AJhereg+OR+cat%3Acd%29&debug=query
I printed query parsing debug information.
you can tell "name_str:Foundation" is lost.
query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
(please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75 6e 64 61 74 69 6f 6e")
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])",
"QParser":"LuceneQParser"}}
--------
but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd",
everything is OK. "name_str:Foundation" is not lost.
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])))",
"parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"QParser":"LuceneQParser"}}
--------
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+name_str%3AJhereg+OR+cat%3Abook+OR+cat%3Acd%29&debug=query
we did a little bit research, and we wander if it is a bug of SolrQueryParser.
more specifically, we think if statement here might be wrong.
https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
Could you please tell us if it is a bug, or it's just a wrong query statement.
Thanks,
Hongtai Xue
Re: strange behavior of solr query parser
Posted by Hongtai Xue <hx...@yahoo-corp.jp>.
Hi Phil.Staley
Thanks for your reply.
but I'm afraid that's a different problem.
Our problem can be confirmed since at least SOLR 7.3.0. (the oldest version we have)
And we guess it might already exists since SOLR-9786.
https://github.com/apache/lucene-solr/commit/bf9db95f218f49bac8e7971eb953a9fd9d13a2f0#diff-269ae02e56283ced3ce781cce21b3147R563
sincerely
hongtai
送信元: "Staley, Phil R - DCF" <Ph...@wisconsin.gov>
Reply-To: "dev@lucene.apache.org" <de...@lucene.apache.org>
日付: 2020年3月2日 月曜日 22:38
宛先: solr_user lucene_apache <so...@lucene.apache.org>, "dev@lucene.apache.org" <de...@lucene.apache.org>
件名: Re: strange behavior of solr query parser
I believe we are experiencing the same thing.
We recently upgraded to our Drupal 8 sites to SOLR 8.3.1. We are now getting reports of certain patterns of search terms resulting in an error that reads, “The website encountered an unexpected error. Please try again later.”
Below is a list of example terms that always result in this error and a similar list that works fine. The problem pattern seems to be a search term that contains 2 or 3 characters followed by a space, followed by additional text.
To confirm that the problem is version 8 of SOLR, I have updated our local and UAT sites with the latest Drupal updates that did include an update to the Search API Solr module and tested the terms below under SOLR 7.7.2, 8.3.1, and 8.4.1. Under version 7.7.2 everything works fine. Under either of the version 8, the problem returns.
Thoughts?
Search terms that result in error
• w-2 agency directory
• agency w-2 directory
• w-2 agency
• w-2 directory
• w2 agency directory
• w2 agency
• w2 directory
Search terms that do not result in error
• w-22 agency directory
• agency directory w-2
• agency w-2directory
• agencyw-2 directory
• w-2
• w2
• agency directory
• agency
• directory
• -2 agency directory
• 2 agency directory
• w-2agency directory
• w2agency directory
From: Hongtai Xue <hx...@yahoo-corp.jp>
Sent: Monday, March 2, 2020 3:45 AM
To: solr_user lucene_apache <so...@lucene.apache.org>
Cc: dev@lucene.apache.org <de...@lucene.apache.org>
Subject: strange behavior of solr query parser
Hi,
Our team found a strange behavior of solr query parser.
In some specific cases, some conditional clauses on unindexed field will be ignored.
for query like, q=A:1 OR B:1 OR A:2 OR B:2
if field B is not indexed(but docValues="true"), "B:1" will be lost.
but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
it will work perfect.
the only difference of two queries is that they are wrote in different orders.
one is ABAB, another is AABB,
■reproduce steps and example explanation
you can easily reproduce this problem on a solr collection with _default configset and exampledocs/books.csv data.
1. create a _default collection
bin/solr create -c books -s 2 -rf 2
2. post books.csv.
bin/post -c books example/exampledocs/books.csv
3. run following query.
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+cat%3Abook+OR+name_str%3AJhereg+OR+cat%3Acd%29&debug=query
I printed query parsing debug information.
you can tell "name_str:Foundation" is lost.
query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
(please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75 6e 64 61 74 69 6f 6e")
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])",
"QParser":"LuceneQParser"}}
--------
but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd",
everything is OK. "name_str:Foundation" is not lost.
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])))",
"parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"QParser":"LuceneQParser"}}
--------
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+name_str%3AJhereg+OR+cat%3Abook+OR+cat%3Acd%29&debug=query
we did a little bit research, and we wander if it is a bug of SolrQueryParser.
more specifically, we think if statement here might be wrong.
https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
Could you please tell us if it is a bug, or it's just a wrong query statement.
Thanks,
Hongtai Xue
Re: strange behavior of solr query parser
Posted by "Staley, Phil R - DCF" <Ph...@wisconsin.gov>.
I believe we are experiencing the same thing.
We recently upgraded to our Drupal 8 sites to SOLR 8.3.1. We are now getting reports of certain patterns of search terms resulting in an error that reads, “The website encountered an unexpected error. Please try again later.”
Below is a list of example terms that always result in this error and a similar list that works fine. The problem pattern seems to be a search term that contains 2 or 3 characters followed by a space, followed by additional text.
To confirm that the problem is version 8 of SOLR, I have updated our local and UAT sites with the latest Drupal updates that did include an update to the Search API Solr module and tested the terms below under SOLR 7.7.2, 8.3.1, and 8.4.1. Under version 7.7.2 everything works fine. Under either of the version 8, the problem returns.
Thoughts?
Search terms that result in error
* w-2 agency directory
* agency w-2 directory
* w-2 agency
* w-2 directory
* w2 agency directory
* w2 agency
* w2 directory
Search terms that do not result in error
* w-22 agency directory
* agency directory w-2
* agency w-2directory
* agencyw-2 directory
* w-2
* w2
* agency directory
* agency
* directory
* -2 agency directory
* 2 agency directory
* w-2agency directory
* w2agency directory
________________________________
From: Hongtai Xue <hx...@yahoo-corp.jp>
Sent: Monday, March 2, 2020 3:45 AM
To: solr_user lucene_apache <so...@lucene.apache.org>
Cc: dev@lucene.apache.org <de...@lucene.apache.org>
Subject: strange behavior of solr query parser
Hi,
Our team found a strange behavior of solr query parser.
In some specific cases, some conditional clauses on unindexed field will be ignored.
for query like, q=A:1 OR B:1 OR A:2 OR B:2
if field B is not indexed(but docValues="true"), "B:1" will be lost.
but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
it will work perfect.
the only difference of two queries is that they are wrote in different orders.
one is ABAB, another is AABB,
■reproduce steps and example explanation
you can easily reproduce this problem on a solr collection with _default configset and exampledocs/books.csv data.
1. create a _default collection
bin/solr create -c books -s 2 -rf 2
2. post books.csv.
bin/post -c books example/exampledocs/books.csv
3. run following query.
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+cat%3Abook+OR+name_str%3AJhereg+OR+cat%3Acd%29&debug=query
I printed query parsing debug information.
you can tell "name_str:Foundation" is lost.
query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
(please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75 6e 64 61 74 69 6f 6e")
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])",
"QParser":"LuceneQParser"}}
--------
but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd",
everything is OK. "name_str:Foundation" is not lost.
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])))",
"parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"QParser":"LuceneQParser"}}
--------
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+name_str%3AJhereg+OR+cat%3Abook+OR+cat%3Acd%29&debug=query
we did a little bit research, and we wander if it is a bug of SolrQueryParser.
more specifically, we think if statement here might be wrong.
https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
Could you please tell us if it is a bug, or it's just a wrong query statement.
Thanks,
Hongtai Xue
Re: strange behavior of solr query parser
Posted by "Staley, Phil R - DCF" <Ph...@wisconsin.gov>.
I believe we are experiencing the same thing.
We recently upgraded to our Drupal 8 sites to SOLR 8.3.1. We are now getting reports of certain patterns of search terms resulting in an error that reads, “The website encountered an unexpected error. Please try again later.”
Below is a list of example terms that always result in this error and a similar list that works fine. The problem pattern seems to be a search term that contains 2 or 3 characters followed by a space, followed by additional text.
To confirm that the problem is version 8 of SOLR, I have updated our local and UAT sites with the latest Drupal updates that did include an update to the Search API Solr module and tested the terms below under SOLR 7.7.2, 8.3.1, and 8.4.1. Under version 7.7.2 everything works fine. Under either of the version 8, the problem returns.
Thoughts?
Search terms that result in error
* w-2 agency directory
* agency w-2 directory
* w-2 agency
* w-2 directory
* w2 agency directory
* w2 agency
* w2 directory
Search terms that do not result in error
* w-22 agency directory
* agency directory w-2
* agency w-2directory
* agencyw-2 directory
* w-2
* w2
* agency directory
* agency
* directory
* -2 agency directory
* 2 agency directory
* w-2agency directory
* w2agency directory
________________________________
From: Hongtai Xue <hx...@yahoo-corp.jp>
Sent: Monday, March 2, 2020 3:45 AM
To: solr_user lucene_apache <so...@lucene.apache.org>
Cc: dev@lucene.apache.org <de...@lucene.apache.org>
Subject: strange behavior of solr query parser
Hi,
Our team found a strange behavior of solr query parser.
In some specific cases, some conditional clauses on unindexed field will be ignored.
for query like, q=A:1 OR B:1 OR A:2 OR B:2
if field B is not indexed(but docValues="true"), "B:1" will be lost.
but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
it will work perfect.
the only difference of two queries is that they are wrote in different orders.
one is ABAB, another is AABB,
■reproduce steps and example explanation
you can easily reproduce this problem on a solr collection with _default configset and exampledocs/books.csv data.
1. create a _default collection
bin/solr create -c books -s 2 -rf 2
2. post books.csv.
bin/post -c books example/exampledocs/books.csv
3. run following query.
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+cat%3Abook+OR+name_str%3AJhereg+OR+cat%3Acd%29&debug=query
I printed query parsing debug information.
you can tell "name_str:Foundation" is lost.
query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
(please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75 6e 64 61 74 69 6f 6e")
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])",
"QParser":"LuceneQParser"}}
--------
but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd",
everything is OK. "name_str:Foundation" is not lost.
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])))",
"parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"QParser":"LuceneQParser"}}
--------
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+name_str%3AJhereg+OR+cat%3Abook+OR+cat%3Acd%29&debug=query
we did a little bit research, and we wander if it is a bug of SolrQueryParser.
more specifically, we think if statement here might be wrong.
https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
Could you please tell us if it is a bug, or it's just a wrong query statement.
Thanks,
Hongtai Xue
Re: strange behavior of solr query parser
Posted by Erick Erickson <er...@gmail.com>.
Yes, it's an inconsistency for sure, thanks!
On Mon, Mar 2, 2020, 17:53 Hongtai Xue <hx...@yahoo-corp.jp> wrote:
> Erik and Jan
>
> Thanks for your reply.
> we will raise a JIRA today (Japanese time).
>
> And, yes, we understand unindexed docvalues field should not be used to
> search.
> one our new solr user just happened to find it, and after doing some
> digging,
> we think we should report it to community.
>
> Thanks
>
> hongtai
>
> 送信元: Jan Høydahl <ja...@cominvent.com>
> Reply-To: "dev@lucene.apache.org" <de...@lucene.apache.org>
> 日付: 2020年3月3日 火曜日 0:09
> 宛先: "dev@lucene.apache.org" <de...@lucene.apache.org>
> 件名: Re: strange behavior of solr query parser
>
> The *_str variant produced by the _default configset is DocValues only, as
> thus intended primarily for faceting and sorting.
> Try changing this line in your schema
>
> <dynamicField
> name="*_str"
> type="strings"
> docValues="true"
> indexed="false"
> stored="false"
> useDocValuesAsStored="false»/>
>
>
> to
>
>
> <dynamicField
> name="*_str"
> type="strings"
> docValues="true"
> indexed="true"
> stored="false"
> useDocValuesAsStored="false»/>
>
>
> …and it will both work and be more performant.
>
> But also file a JIRA since it is obviously a bug - matching a string from
> DocValues should still work even if slow.
>
> Jan
>
>
> 2. mar. 2020 kl. 15:35 skrev Erick Erickson <mailto:
> erickerickson@gmail.com>:
>
> Hongtai Xue:
>
> First, many thanks for reporting this in such detail, it really helps and
> it’s obvious you’ve dug into the problem rather than just thrown it over
> the wall.
>
> Please do raise a JIRA, no matter what the behaviors should be the same.
>
> One caution: Searching on a docValues=“true” indexed=“false” will not be
> performant as the index grows last I knew (think “table scan”). DocValues
> is specifically designed to answer the question “for doc y, what is the
> value if field x” and this form is asking “for value x, what docs contain
> it”. At least check with a reasonably large data set before allowing that
> in your app. Personally, I’d like to see the ability to search on a dv-only
> field restricted, but that’s another story...
>
> That is not to say the behavior you’re reporting is OK, it’s not. Just a
> caution for you going forward.
>
> Best,
> Erick
>
>
> On Mar 2, 2020, at 03:45, Hongtai Xue <ma...@yahoo-corp.jp> wrote:
> Hi,
>
> Our team found a strange behavior of solr query parser.
> In some specific cases, some conditional clauses on unindexed field will
> be ignored.
>
> for query like, q=A:1 OR B:1 OR A:2 OR B:2
> if field B is not indexed(but docValues="true"), "B:1" will be lost.
>
> but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
> it will work perfect.
>
> the only difference of two queries is that they are wrote in different
> orders.
> one is ABAB, another is AABB,
>
> ■reproduce steps and example explanation
> you can easily reproduce this problem on a solr collection with _default
> configset and exampledocs/books.csv data.
>
> 1. create a _default collection
> bin/solr create -c books -s 2 -rf 2
>
> 2. post books.csv.
> bin/post -c books example/exampledocs/books.csv
>
> 3. run following query.
>
> http://localhost:8983/solr/books/select?q=+(name_str:Foundation+OR+cat:book+OR+name_str:Jhereg+OR+cat:cd)&debug=query
>
>
> I printed query parsing debug information.
> you can tell "name_str:Foundation" is lost.
>
> query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
> (please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75
> 6e 64 61 74 69 6f 6e")
> --------
> "debug":{
> "rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg
> OR cat:cd)",
> "querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR
> cat:cd)",
> "parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a
> 68 65 72 65 67]]))",
> "parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65
> 67] TO [4a 68 65 72 65 67]])",
> "QParser":"LuceneQParser"}}
> --------
>
> but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR
> cat:cd",
> everything is OK. "name_str:Foundation" is not lost.
> --------
> "debug":{
> "rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book
> OR cat:cd)",
> "querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR
> cat:cd)",
> "parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69
> 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67]
> TO [4a 68 65 72 65 67]])))",
> "parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64
> 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72
> 65 67] TO [4a 68 65 72 65 67]]))",
> "QParser":"LuceneQParser"}}
> --------
>
> http://localhost:8983/solr/books/select?q=+(name_str:Foundation+OR+name_str:Jhereg+OR+cat:book+OR+cat:cd)&debug=query
>
> we did a little bit research, and we wander if it is a bug of
> SolrQueryParser.
> more specifically, we think if statement here might be wrong.
>
> https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
>
> Could you please tell us if it is a bug, or it's just a wrong query
> statement.
>
> Thanks,
> Hongtai Xue
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: strange behavior of solr query parser
Posted by Hongtai Xue <hx...@yahoo-corp.jp>.
Erik and Jan
Thanks for your reply.
we will raise a JIRA today (Japanese time).
And, yes, we understand unindexed docvalues field should not be used to search.
one our new solr user just happened to find it, and after doing some digging,
we think we should report it to community.
Thanks
hongtai
送信元: Jan Høydahl <ja...@cominvent.com>
Reply-To: "dev@lucene.apache.org" <de...@lucene.apache.org>
日付: 2020年3月3日 火曜日 0:09
宛先: "dev@lucene.apache.org" <de...@lucene.apache.org>
件名: Re: strange behavior of solr query parser
The *_str variant produced by the _default configset is DocValues only, as thus intended primarily for faceting and sorting.
Try changing this line in your schema
<dynamicField
name="*_str"
type="strings"
docValues="true"
indexed="false"
stored="false"
useDocValuesAsStored="false»/>
to
<dynamicField
name="*_str"
type="strings"
docValues="true"
indexed="true"
stored="false"
useDocValuesAsStored="false»/>
…and it will both work and be more performant.
But also file a JIRA since it is obviously a bug - matching a string from DocValues should still work even if slow.
Jan
2. mar. 2020 kl. 15:35 skrev Erick Erickson <ma...@gmail.com>:
Hongtai Xue:
First, many thanks for reporting this in such detail, it really helps and it’s obvious you’ve dug into the problem rather than just thrown it over the wall.
Please do raise a JIRA, no matter what the behaviors should be the same.
One caution: Searching on a docValues=“true” indexed=“false” will not be performant as the index grows last I knew (think “table scan”). DocValues is specifically designed to answer the question “for doc y, what is the value if field x” and this form is asking “for value x, what docs contain it”. At least check with a reasonably large data set before allowing that in your app. Personally, I’d like to see the ability to search on a dv-only field restricted, but that’s another story...
That is not to say the behavior you’re reporting is OK, it’s not. Just a caution for you going forward.
Best,
Erick
On Mar 2, 2020, at 03:45, Hongtai Xue <ma...@yahoo-corp.jp> wrote:
Hi,
Our team found a strange behavior of solr query parser.
In some specific cases, some conditional clauses on unindexed field will be ignored.
for query like, q=A:1 OR B:1 OR A:2 OR B:2
if field B is not indexed(but docValues="true"), "B:1" will be lost.
but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
it will work perfect.
the only difference of two queries is that they are wrote in different orders.
one is ABAB, another is AABB,
■reproduce steps and example explanation
you can easily reproduce this problem on a solr collection with _default configset and exampledocs/books.csv data.
1. create a _default collection
bin/solr create -c books -s 2 -rf 2
2. post books.csv.
bin/post -c books example/exampledocs/books.csv
3. run following query.
http://localhost:8983/solr/books/select?q=+(name_str:Foundation+OR+cat:book+OR+name_str:Jhereg+OR+cat:cd)&debug=query
I printed query parsing debug information.
you can tell "name_str:Foundation" is lost.
query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
(please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75 6e 64 61 74 69 6f 6e")
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
"parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])",
"QParser":"LuceneQParser"}}
--------
but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd",
everything is OK. "name_str:Foundation" is not lost.
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
"parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])))",
"parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
"QParser":"LuceneQParser"}}
--------
http://localhost:8983/solr/books/select?q=+(name_str:Foundation+OR+name_str:Jhereg+OR+cat:book+OR+cat:cd)&debug=query
we did a little bit research, and we wander if it is a bug of SolrQueryParser.
more specifically, we think if statement here might be wrong.
https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
Could you please tell us if it is a bug, or it's just a wrong query statement.
Thanks,
Hongtai Xue
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: strange behavior of solr query parser
Posted by Jan Høydahl <ja...@cominvent.com>.
The *_str variant produced by the _default configset is DocValues only, as thus intended primarily for faceting and sorting.
Try changing this line in your schema
<dynamicField name="*_str" type="strings" docValues="true" indexed="false" stored="false" useDocValuesAsStored="false»/>
to
<dynamicField name="*_str" type="strings" docValues="true" indexed="true" stored="false" useDocValuesAsStored="false»/>
…and it will both work and be more performant.
But also file a JIRA since it is obviously a bug - matching a string from DocValues should still work even if slow.
Jan
> 2. mar. 2020 kl. 15:35 skrev Erick Erickson <er...@gmail.com>:
>
> Hongtai Xue:
>
> First, many thanks for reporting this in such detail, it really helps and it’s obvious you’ve dug into the problem rather than just thrown it over the wall.
>
> Please do raise a JIRA, no matter what the behaviors should be the same.
>
> One caution: Searching on a docValues=“true” indexed=“false” will not be performant as the index grows last I knew (think “table scan”). DocValues is specifically designed to answer the question “for doc y, what is the value if field x” and this form is asking “for value x, what docs contain it”. At least check with a reasonably large data set before allowing that in your app. Personally, I’d like to see the ability to search on a dv-only field restricted, but that’s another story...
>
> That is not to say the behavior you’re reporting is OK, it’s not. Just a caution for you going forward.
>
> Best,
> Erick
>
>> On Mar 2, 2020, at 03:45, Hongtai Xue <hx...@yahoo-corp.jp> wrote:
>>
>>
>> Hi,
>>
>> Our team found a strange behavior of solr query parser.
>> In some specific cases, some conditional clauses on unindexed field will be ignored.
>>
>> for query like, q=A:1 OR B:1 OR A:2 OR B:2
>> if field B is not indexed(but docValues="true"), "B:1" will be lost.
>>
>> but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
>> it will work perfect.
>>
>> the only difference of two queries is that they are wrote in different orders.
>> one is ABAB, another is AABB,
>>
>> ■reproduce steps and example explanation
>> you can easily reproduce this problem on a solr collection with _default configset and exampledocs/books.csv data.
>>
>> 1. create a _default collection
>> bin/solr create -c books -s 2 -rf 2
>>
>> 2. post books.csv.
>> bin/post -c books example/exampledocs/books.csv
>>
>> 3. run following query.
>> http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+cat%3Abook+OR+name_str%3AJhereg+OR+cat%3Acd%29&debug=query
>>
>>
>> I printed query parsing debug information.
>> you can tell "name_str:Foundation" is lost.
>>
>> query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
>> (please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75 6e 64 61 74 69 6f 6e")
>> --------
>> "debug":{
>> "rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
>> "querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
>> "parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
>> "parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])",
>> "QParser":"LuceneQParser"}}
>> --------
>>
>> but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd",
>> everything is OK. "name_str:Foundation" is not lost.
>> --------
>> "debug":{
>> "rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
>> "querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
>> "parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])))",
>> "parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
>> "QParser":"LuceneQParser"}}
>> --------
>> http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+name_str%3AJhereg+OR+cat%3Abook+OR+cat%3Acd%29&debug=query
>>
>> we did a little bit research, and we wander if it is a bug of SolrQueryParser.
>> more specifically, we think if statement here might be wrong.
>> https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
>>
>> Could you please tell us if it is a bug, or it's just a wrong query statement.
>>
>> Thanks,
>> Hongtai Xue
Re: strange behavior of solr query parser
Posted by Erick Erickson <er...@gmail.com>.
Hongtai Xue:
First, many thanks for reporting this in such detail, it really helps and it’s obvious you’ve dug into the problem rather than just thrown it over the wall.
Please do raise a JIRA, no matter what the behaviors should be the same.
One caution: Searching on a docValues=“true” indexed=“false” will not be performant as the index grows last I knew (think “table scan”). DocValues is specifically designed to answer the question “for doc y, what is the value if field x” and this form is asking “for value x, what docs contain it”. At least check with a reasonably large data set before allowing that in your app. Personally, I’d like to see the ability to search on a dv-only field restricted, but that’s another story...
That is not to say the behavior you’re reporting is OK, it’s not. Just a caution for you going forward.
Best,
Erick
> On Mar 2, 2020, at 03:45, Hongtai Xue <hx...@yahoo-corp.jp> wrote:
>
>
> Hi,
>
> Our team found a strange behavior of solr query parser.
> In some specific cases, some conditional clauses on unindexed field will be ignored.
>
> for query like, q=A:1 OR B:1 OR A:2 OR B:2
> if field B is not indexed(but docValues="true"), "B:1" will be lost.
>
> but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
> it will work perfect.
>
> the only difference of two queries is that they are wrote in different orders.
> one is ABAB, another is AABB,
>
> ■reproduce steps and example explanation
> you can easily reproduce this problem on a solr collection with _default configset and exampledocs/books.csv data.
>
> 1. create a _default collection
> bin/solr create -c books -s 2 -rf 2
>
> 2. post books.csv.
> bin/post -c books example/exampledocs/books.csv
>
> 3. run following query.
> http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+cat%3Abook+OR+name_str%3AJhereg+OR+cat%3Acd%29&debug=query
>
>
> I printed query parsing debug information.
> you can tell "name_str:Foundation" is lost.
>
> query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
> (please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75 6e 64 61 74 69 6f 6e")
> --------
> "debug":{
> "rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
> "querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd)",
> "parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
> "parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])",
> "QParser":"LuceneQParser"}}
> --------
>
> but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd",
> everything is OK. "name_str:Foundation" is not lost.
> --------
> "debug":{
> "rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
> "querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd)",
> "parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]])))",
> "parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61 74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65 67] TO [4a 68 65 72 65 67]]))",
> "QParser":"LuceneQParser"}}
> --------
> http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+name_str%3AJhereg+OR+cat%3Abook+OR+cat%3Acd%29&debug=query
>
> we did a little bit research, and we wander if it is a bug of SolrQueryParser.
> more specifically, we think if statement here might be wrong.
> https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
>
> Could you please tell us if it is a bug, or it's just a wrong query statement.
>
> Thanks,
> Hongtai Xue
Re: strange behavior of solr query parser
Posted by Erick Erickson <er...@gmail.com>.
Hongtai:
First, many thanks for reporting this in such detail, it really helps and
it’s obvious you’ve dug into the problem rather than just thrown it over
the wall.
Please go ahead and raise a JIRA
Best,
Erick
On Mar 2, 2020, at 03:45, Hongtai Xue <hx...@yahoo-corp.jp> wrote:
Hi,
Our team found a strange behavior of solr query parser.
In some specific cases, some conditional clauses on unindexed field will be
ignored.
for query like, q=A:1 OR B:1 OR A:2 OR B:2
if field B is not indexed(but docValues="true"), "B:1" will be lost.
but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,
it will work perfect.
the only difference of two queries is that they are wrote in different
orders.
one is ABAB, another is AABB,
■reproduce steps and example explanation
you can easily reproduce this problem on a solr collection with _default
configset and exampledocs/books.csv data.
1. create a _default collection
bin/solr create -c books -s 2 -rf 2
2. post books.csv.
bin/post -c books example/exampledocs/books.csv
3. run following query.
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+cat%3Abook+OR+name_str%3AJhereg+OR+cat%3Acd%29&debug=query
I printed query parsing debug information.
you can tell "name_str:Foundation" is lost.
query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"
(please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75
6e 64 61 74 69 6f 6e")
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg
OR cat:cd)",
"querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR
cat:cd)",
"parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a
68 65 72 65 67]]))",
"parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67]
TO [4a 68 65 72 65 67]])",
"QParser":"LuceneQParser"}}
--------
but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR
cat:cd",
everything is OK. "name_str:Foundation" is not lost.
--------
"debug":{
"rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book
OR cat:cd)",
"querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR
cat:cd)",
"parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69
6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67]
TO [4a 68 65 72 65 67]])))",
"parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61
74 69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65
67] TO [4a 68 65 72 65 67]]))",
"QParser":"LuceneQParser"}}
--------
http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+name_str%3AJhereg+OR+cat%3Abook+OR+cat%3Acd%29&debug=query
we did a little bit research, and we wander if it is a bug of
SolrQueryParser.
more specifically, we think if statement here might be wrong.
https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711
Could you please tell us if it is a bug, or it's just a wrong query
statement.
Thanks,
Hongtai Xue