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 Brian Hurt <bh...@gmail.com> on 2013/04/24 16:59:29 UTC
Noob question: why doesn't this query work?
So, I'm executing the following query:
id:"6178dB=@Fm" AND i_0:"613OFS" AND (i_3:"6111" OR i_3:"1yyy\~") AND (NOT
id:"6178ZwWj5m" OR numfields:[* TO "6114"] OR d_4:"false" OR NOT
i_4:"6142E=m")
It's machine generated, which explains the redundancies. The problem is
that the query returns no results- but there is a document that should
match- it has an id of "6178dB=@Fm", an i_0 field of "613OFS", an i_3 field
of "6111", a numfields of "611A", a d_4 of true (but this shouldn't
matter), and an i_4 of "6142F1S".
The problem seems to be with the negations. I did try to replace the NOT's
with -'s, so, for example, NOT id:"6178ZwWj5m" would become
-id:"6178ZwWj5m", and this didn't seem to work.
Help? What's wrong with the query? Thanks.
Brian
Re: Noob question: why doesn't this query work?
Posted by Chris Hostetter <ho...@fucit.org>.
: This could be the problem. This is query is machine generated, so I don't
: care how ugly it is. Does this apply even to inner queries? I.e., should
: that last clause be (*:* -i_4:6142E=m") instead of (NOT I-4:"6142E=m")?
yes -- you can't exclude "6142E=m" w/o defining what set (ie: the set
of all documents: *:*) you are excluding it from.
Related reading about building up nested queries with parens and using the
AND/OR/NOT syntax...
http://www.lucidimagination.com/blog/2011/12/28/why-not-and-or-and-not/
-Hoss
Re: Noob question: why doesn't this query work?
Posted by Shawn Heisey <so...@elyograg.org>.
On 4/24/2013 12:13 PM, Brian Hurt wrote:
>> If the boolean layout you have is really what you want, then you need to
>> change the negation queries to (*:* -query) instead, because pure
>> negative queries are not supported. That syntax says "all documents
>> except those that match the query." For simple negation queries, Solr
>> can figure out that it needs to add the *:* internally, but this query
>> is more complex.
>
> This could be the problem. This is query is machine generated, so I don't
> care how ugly it is. Does this apply even to inner queries? I.e., should
> that last clause be (*:* -i_4:6142E=m") instead of (NOT I-4:"6142E=m")?
Exactly right.
> I wash all strings through ClientUtils.escapeQueryChars always, so this
> isn't a problem. That string should just be "1yyy~", the ~ was getting
> escaped.
A quick check with debugQuery seems to confirm my thoughts on this - if
you have the quotes, the escaping isn't necessary, although including it
appears to be working correctly too. Depending on exactly what field
type you have, you might be good there.
>> Don't use quotes unless you really are after phrase queries or you can't
>> escape special characters. You might actually need phrase queries for
>> some of this, but I would try simple one-field queries without the
>> quotes to see whether you need them. I have no idea what happens if you
>> include quotes inside a range query (the "6114"), but it might not do
>> what you expect. I would definitely remove the quotes from that part of
>> the query.
>
> This is another solid possibility, although it might raise some
> difficulties for me- I need to be able to support literal string
> comparisons, so I'm not sure how well this would support the query s_7 <=
> "some string with spaces" sorts of queries. But some experimentation here
> is definitely in order.
Due to the query parser trying to be smart, quotes appear to be
necessary if spaces are part of your indexed values and your query.
Since I now know that you don't want to negate the range query, it makes
sense for me to tell you that a value of 611A is outside the range [* TO
6114], because numbers are "lower" than letters when doing string
comparisons. This was why I thought you might be trying to negate the
entire query clause - it's the only way that particular piece would match.
Thanks,
Shawn
Re: Noob question: why doesn't this query work?
Posted by Brian Hurt <bh...@gmail.com>.
Thanks for your reponse. You've given me some solid leads.
On Wed, Apr 24, 2013 at 11:25 AM, Shawn Heisey <so...@elyograg.org> wrote:
> On 4/24/2013 8:59 AM, Brian Hurt wrote:
> > So, I'm executing the following query:
> > id:"6178dB=@Fm" AND i_0:"613OFS" AND (i_3:"6111" OR i_3:"1yyy\~") AND
> (NOT
> > id:"6178ZwWj5m" OR numfields:[* TO "6114"] OR d_4:"false" OR NOT
> > i_4:"6142E=m")
> >
> > It's machine generated, which explains the redundancies. The problem is
> > that the query returns no results- but there is a document that should
> > match- it has an id of "6178dB=@Fm", an i_0 field of "613OFS", an i_3
> field
> > of "6111", a numfields of "611A", a d_4 of true (but this shouldn't
> > matter), and an i_4 of "6142F1S".
> >
> > The problem seems to be with the negations. I did try to replace the
> NOT's
> > with -'s, so, for example, NOT id:"6178ZwWj5m" would become
> > -id:"6178ZwWj5m", and this didn't seem to work.
> >
> > Help? What's wrong with the query? Thanks.
>
> It looks like you might have meant to negate all of the query clauses
> inside the last set of parentheses. That's not what your actual query
> says. If you change your negation so that the NOT is outside the
> parentheses, so that it reads "AND NOT (... OR ...)", that should fix
> that part of it.
>
>
No, I meant the NOT to only bind to the next id. So the query I wanted was:
id:"6178dB=@Fm" AND i_0:"613OFS" AND (i_3:"6111" OR i_3:"1yyy\~") AND ((NOT
id:"6178ZwWj5m") OR numfields:[* TO "6114"] OR d_4:"false" OR (NOT
i_4:"6142E=m"))
> If the boolean layout you have is really what you want, then you need to
> change the negation queries to (*:* -query) instead, because pure
> negative queries are not supported. That syntax says "all documents
> except those that match the query." For simple negation queries, Solr
> can figure out that it needs to add the *:* internally, but this query
> is more complex.
>
>
This could be the problem. This is query is machine generated, so I don't
care how ugly it is. Does this apply even to inner queries? I.e., should
that last clause be (*:* -i_4:6142E=m") instead of (NOT I-4:"6142E=m")?
> A few other possible problems:
>
> A backslash is a special character used to escape other special
> characters, so you *might* need two of them - one to say 'the next
> character is literal' and one to actually be the backslash. If you
> follow the advice in the next paragraph, I can guarantee this will be
> the case. For that reason, you might want to keep the quotes on fields
> that might contain characters that have special meaning to the Solr
> query parser.
>
>
I wash all strings through ClientUtils.escapeQueryChars always, so this
isn't a problem. That string should just be "1yyy~", the ~ was getting
escaped.
> Don't use quotes unless you really are after phrase queries or you can't
> escape special characters. You might actually need phrase queries for
> some of this, but I would try simple one-field queries without the
> quotes to see whether you need them. I have no idea what happens if you
> include quotes inside a range query (the "6114"), but it might not do
> what you expect. I would definitely remove the quotes from that part of
> the query.
>
>
This is another solid possibility, although it might raise some
difficulties for me- I need to be able to support literal string
comparisons, so I'm not sure how well this would support the query s_7 <=
"some string with spaces" sorts of queries. But some experimentation here
is definitely in order.
> Thanks,
> Shawn
>
>
Re: Noob question: why doesn't this query work?
Posted by Shawn Heisey <so...@elyograg.org>.
On 4/24/2013 8:59 AM, Brian Hurt wrote:
> So, I'm executing the following query:
> id:"6178dB=@Fm" AND i_0:"613OFS" AND (i_3:"6111" OR i_3:"1yyy\~") AND (NOT
> id:"6178ZwWj5m" OR numfields:[* TO "6114"] OR d_4:"false" OR NOT
> i_4:"6142E=m")
>
> It's machine generated, which explains the redundancies. The problem is
> that the query returns no results- but there is a document that should
> match- it has an id of "6178dB=@Fm", an i_0 field of "613OFS", an i_3 field
> of "6111", a numfields of "611A", a d_4 of true (but this shouldn't
> matter), and an i_4 of "6142F1S".
>
> The problem seems to be with the negations. I did try to replace the NOT's
> with -'s, so, for example, NOT id:"6178ZwWj5m" would become
> -id:"6178ZwWj5m", and this didn't seem to work.
>
> Help? What's wrong with the query? Thanks.
It looks like you might have meant to negate all of the query clauses
inside the last set of parentheses. That's not what your actual query
says. If you change your negation so that the NOT is outside the
parentheses, so that it reads "AND NOT (... OR ...)", that should fix
that part of it.
If the boolean layout you have is really what you want, then you need to
change the negation queries to (*:* -query) instead, because pure
negative queries are not supported. That syntax says "all documents
except those that match the query." For simple negation queries, Solr
can figure out that it needs to add the *:* internally, but this query
is more complex.
A few other possible problems:
A backslash is a special character used to escape other special
characters, so you *might* need two of them - one to say 'the next
character is literal' and one to actually be the backslash. If you
follow the advice in the next paragraph, I can guarantee this will be
the case. For that reason, you might want to keep the quotes on fields
that might contain characters that have special meaning to the Solr
query parser.
Don't use quotes unless you really are after phrase queries or you can't
escape special characters. You might actually need phrase queries for
some of this, but I would try simple one-field queries without the
quotes to see whether you need them. I have no idea what happens if you
include quotes inside a range query (the "6114"), but it might not do
what you expect. I would definitely remove the quotes from that part of
the query.
Thanks,
Shawn