I think this is the issue with top-level negative clause. Lucene does not know what "-x" means without "*:* -x" to establish the baseline set to subtract from. Solr has a workaround for top-level negative query, so "-WithinPrefixTreeQuery..." triggers that special treatment. But "+(-WithinPrefixTreeQuery" does not and therefore it silently fails.
There is quite a bit of discussion in the archives about it. I am just summarizing it, hopefully correctly. You can search the terms above to find more detailed answers. Regards, Alex. On 18 September 2018 at 15:05, Antelmo Aguilar <aagui...@nd.edu> wrote: > Hi Alex and Erick, > > We could possibly put them in fq, but how we set everything up would make > it hard to do so, but going that route might be the only option. > > I did take a look at the parsed query and this is the difference: > > This is the one that works: > "-WithinPrefixTreeQuery(fieldName=collection_date_range,queryShape=[2000 TO > 2018-09-18],detailLevel=9,prefixGridScanLevel=7) > -WithinPrefixTreeQuery(fieldName=collection_date_range,queryShape=[1960 TO > 1998-09-18],detailLevel=9,prefixGridScanLevel=7) > +IntersectsPrefixTreeQuery(fieldName=collection_season,queryShape=1999-05,detailLevel=9,prefixGridScanLevel=8)" > > This is the one that does not work > "+(-WithinPrefixTreeQuery(fieldName=collection_date_range,queryShape=[2000 > TO 2018-09-18],detailLevel=9,prefixGridScanLevel=7) > -WithinPrefixTreeQuery(fieldName=collection_date_range,queryShape=[1960 TO > 1998-09-18],detailLevel=9,prefixGridScanLevel=7)) > +IntersectsPrefixTreeQuery(fieldName=collection_season,queryShape=1999-05,detailLevel=9,prefixGridScanLevel=8)" > > If someone knows by just looking at these queries why I get no results in > the second one, I would appreciate it. From looking at the page Erick > pointed out, I do not think it covers my case? ((-X AND -Y) AND Z) > > Sorry for the trouble and thanks again! > > Best, > Antelmo > > On Tue, Sep 18, 2018 at 2:56 PM, Erick Erickson <erickerick...@gmail.com> > wrote: > >> Also, Solr does _not_ implement strict Boolean logic, although with >> appropriate parentheses you can get it to look like Boolean logic. >> See: https://lucidworks.com/2011/12/28/why-not-and-or-and-not/. >> >> Additionally, for _some_ clauses a pure-not query is translated into >> *:* -pure_not_query which is helpful, but occasionally confusing. >> >> Best, >> Erick >> On Tue, Sep 18, 2018 at 11:43 AM Alexandre Rafalovitch >> <arafa...@gmail.com> wrote: >> > >> > Have a look at what debug shows in the parsed query. I think every >> > bracket is quite significant actually and you are generating a >> > different type of clause. >> > >> > Also, have you thought about putting those individual clauses into >> > 'fq' instead of jointly into 'q'? This may give you faster search too, >> > as Solr will not have to worry about ranking. >> > >> > Regards, >> > Alex. >> > >> > On 18 September 2018 at 14:38, Antelmo Aguilar <aagui...@nd.edu> wrote: >> > > Hi, >> > > >> > > I am doing some date queries and I was wondering if there is some way >> of >> > > getting this query to work. >> > > >> > > ( ( !{!field f=collection_date_range op=Within v='[2000-01-01 TO >> > > 2018-09-18]'} AND !{!field f=collection_date_range op=Within >> v='[1960-01-01 >> > > TO 1998-09-18]'} ) AND collection_season:([1999-05 TO 1999-05]) ) >> > > >> > > I understand that I could just not do NOT queries and instead search >> for >> > > 1998-09-18 TO 2000-01-01, but doing NOT queries gives me more results >> (e.g >> > > records that do not have collection_date_range defined). >> > > >> > > If I remove the parenthesis enclosing the NOT queries, it works. >> Without >> > > the parenthesis the query does not return results though. So the query >> > > below, does work. >> > > >> > > ( !{!field f=collection_date_range op=Within v='[2000-01-01 TO >> > > 2018-09-18]'} AND !{!field f=collection_date_range op=Within >> v='[1960-01-01 >> > > TO 1998-09-18]'} AND collection_season:([1999-05 TO 1999-05]) ) >> > > >> > > Any insight would be appreciated. I really do not see the reason why >> the >> > > parenthesis enclosing the NOT queries would cause it to not return >> results. >> > > >> > > Best, >> > > Antelmo >>
