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 > >