Well, it makes sense however for most use cases. Lets say you have a normal user enter a query WATER:WHEN IS IT NOT A LIQUID if it was interpreted strictly it would throw an error unless WATER is a field, and "NOT" needs to be turned into "not" as well.
On Wed, Oct 18, 2017 at 3:46 PM, Beach, Daniel <daniel.be...@spglobal.com> wrote: > Yes, that appears to be true unless I'm missing something obvious. > > It seems like in this case Solr should either 1) search against the fields > that it /does/ know about in a given collection normally, or 2) return an > error. That would be more intuitive than returning results but with > different search logic. > > Currently we add placeholder fields to other collections in an alias to > get around this if required, but it's messy. > > -----Original Message----- > From: David Hastings [mailto:hastings.recurs...@gmail.com] > Sent: Wednesday, October 18, 2017 3:20 PM > To: solr-user@lucene.apache.org > Subject: Re: Querying fields that don't exist in every collection > > I may be wrong here, but what i think is happening is the edismax parser > sees a field that doesn't exist, and therefore "believes" all logic you > entered into the query is a complete mistake and negates it as such. so > NOT becomes the word not and * becomes whitespace. > > On Wed, Oct 18, 2017 at 3:15 PM, Beach, Daniel <daniel.be...@spglobal.com> > wrote: > > > Hello all, > > > > I'm running into an issue where adding a field to the qf changes the > > parsed query if that field doesn't exist in the Solr index. Our use > > case for doing this is that we have multiple collections and many of > > our queries leverage aliases to search across several of them > > simultaneously. While we have a common group of fields that is shared > > across schemas, it is often the case that we need to use > > collection-specific fields to boost one content type over another. > > > > Here is the query debug output from a query that only searches on > > existing fields. This is the intended outcome. > > > > q=companies%20NOT%20brands*&qf=Text&wt=json&debug=query& > > defType=edismax > > > > "rawquerystring":"companies NOT brands*", > > "querystring":"companies NOT brands*", > > "parsedquery":"(+(DisjunctionMaxQuery((Text:company)) > > -DisjunctionMaxQuery((Text:brands*))))/no_coord", > > "parsedquery_toString":"+((Text:company) -(Text:brands*))", > > "QParser":"ExtendedDismaxQParser", > > > > > > When a "BOGUS" field name is added to the second query suddenly the > > query operators aren't interpreted correctly, and wildcards get dropped. > > > > q=companies%20NOT%20brands*&qf=Text%20BOGUS&wt=json&debug= > > query&defType=edismax > > > > "rawquerystring":"companies NOT brands*", > > "querystring":"companies NOT brands*", > > "parsedquery":"(+(DisjunctionMaxQuery((Text:company)) > > DisjunctionMaxQuery((Text:not)) DisjunctionMaxQuery((Text: > > brand))))/no_coord", > > "parsedquery_toString":"+((Text:company) (Text:not) (Text:brand))", > > "QParser":"ExtendedDismaxQParser" > > > > > > These results are from Solr 6.5.0 and 5.5, querying against a single > > collection endpoint. Is this Solr's expected functionality? Hopefully > > I'm just blanking on something simple here. > > > > Thanks, > > Daniel Beach > > > > ________________________________ > > > > The information contained in this message is intended only for the > > recipient, and may be a confidential attorney-client communication or > > may otherwise be privileged and confidential and protected from > > disclosure. If the reader of this message is not the intended > > recipient, or an employee or agent responsible for delivering this > > message to the intended recipient, please be aware that any > > dissemination or copying of this communication is strictly prohibited. > > If you have received this communication in error, please immediately > > notify us by replying to the message and deleting it from your > > computer. S&P Global Inc. reserves the right, subject to applicable > > local law, to monitor, review and process the content of any > > electronic message or information sent to or from S&P Global Inc. > > e-mail addresses without informing the sender or recipient of the > > message. By sending electronic message or information to S&P Global > > Inc. e-mail addresses you, as the sender, are consenting to S&P Global > Inc. processing any of your personal data therein. > > > > ________________________________ > > The information contained in this message is intended only for the > recipient, and may be a confidential attorney-client communication or may > otherwise be privileged and confidential and protected from disclosure. If > the reader of this message is not the intended recipient, or an employee or > agent responsible for delivering this message to the intended recipient, > please be aware that any dissemination or copying of this communication is > strictly prohibited. If you have received this communication in error, > please immediately notify us by replying to the message and deleting it > from your computer. S&P Global Inc. reserves the right, subject to > applicable local law, to monitor, review and process the content of any > electronic message or information sent to or from S&P Global Inc. e-mail > addresses without informing the sender or recipient of the message. By > sending electronic message or information to S&P Global Inc. e-mail > addresses you, as the sender, are consenting to S&P Global Inc. processing > any of your personal data therein. >
