Thanks for your reponse.  You've given me some solid leads.

On Wed, Apr 24, 2013 at 11:25 AM, Shawn Heisey <s...@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
>
>

Reply via email to