Yes, fq’s make up constraints in conjunction with q. The issue here though is
_clauses_.A single negative clause matches nothing. There is syntactic
sugar at the Solr level to allow for q and fq’s to have a top-level single
negative clause, like q=-type:pdf to return all non-pdf docs. Tha
Thanks Erik, This helped and the query is running and gives results as
expected.
Thanks for the insight, my understanding here was that fq parameter works
on the result set of q parameter which is *:* here. shouldn't that be the
case here?
Thanks,
Abhishek
On Tue, Jun 13, 2017 at 6:02 PM, Erik
Inner purely negative queries match nothing. A query is about matching, and
skipping over things that don’t match. The fix is when using (-something) to
do (*:* -something) to match everything and skip the negative clause items.
In your example, try fq=((*:* -documentTypeId:3) AND companyId:29
Hi Everyone,
I have hit a weird behavior of Boolean Query, when I am
running the query with below param’s it’s not behaving as expected. can
you please help me understand the behavior here?
q=*:*&fq=((-documentTypeId:3)+AND+companyId:29096)&version=2.2&start=0&rows=10&indent=on
On Sun, Feb 8, 2015 at 9:04 PM, Uwe Schindler wrote:
> Hi,
>
> Lucene does not use algebraic / boolean logic! Maybe review this blog
> post: https://lucidworks.com/blog/why-not-and-or-and-not/
This article is an old classic.
The "plus, minus, nothing" operators aren't without their issues
either
lliker [mailto:ikoelli...@axsone.com]
> Sent: Friday, February 06, 2015 10:47 PM
> To: java-user@lucene.apache.org
> Subject: Lucene query behavior using NOT
>
> Hello,
> I am trying to understand whether I am using the NOT operator correctly. I
> have the following scenario:
>
Hello,
I am trying to understand whether I am using the NOT operator correctly. I have
the following scenario:
Query 1 = body:(a OR NOT b)
This is parsed as: (body:a) -(body:b) and finds 96,620 hits
Query 2 = body:(a OR (*:* AND NOT b))
This is parsed as: (body:a) (+*:* -(body:b)) and finds 1
You can also specify a large slop in your phrase (e.g.
"arcos biosciences"~500 which will take distance into
account when scoring, although it may not be enough
to rank the document where you want. Sujit's comment
is probably a better place to start.
Best
Erick
On Tue, Apr 26, 2011 at 2:59 PM, Su
Hi Deepak,
Would something like this work in your case?
"Arcos Bioscience"^2.0 "Arcos" "Bioscience"
ie, a BooleanQuery with the full phrase boosted OR'd with a query on
each word?
-sujit
On Tue, 2011-04-26 at 14:46 -0400, Deepak Konidena wrote:
> Hi,
>
> Currently when I type in Arcos Bioscie
Hi,
Currently when I type in Arcos Bioscience in my lucene search, it returns all
those documents with
either Arcos or Bioscience at the top of the search results and the actual
document containing
"Arcos Bioscience" somewhere in the middle/bottom.
The desired behavior is to rank those documen
o S
albertos_at_optimus-corp_dot_com
-Original Message-
From: Paul Elschot [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 27, 2005 1:04 AM
To: java-user@lucene.apache.org
Subject: Re: query behavior
On Tuesday 27 September 2005 01:13, Chris Hostetter wrote:
>
> I *believe* that b
er@lucene.apache.org
> : To: java-user@lucene.apache.org
> : Subject: query behavior
> :
> : Hi!
> :
> : I learnt from a mailing list archive that the following applies:
> :
> :
> :
> : -
> : Tue, 06 Jan 2004
> : [...]
> : I have a
6 Sep 2005 16:46:45 -0600
: From: Alberto Squassabia <[EMAIL PROTECTED]>
: Reply-To: java-user@lucene.apache.org
: To: java-user@lucene.apache.org
: Subject: query behavior
:
: Hi!
:
: I learnt from a mailing list archive that the following applies:
:
:
:
: -
:
Hi!
I learnt from a mailing list archive that the following applies:
-
Tue, 06 Jan 2004
[...]
I have a index with documents that have only 2 fields, the first
(unique) is 'very unique', in that most document have at least somewhat
varying terms, the second is a
14 matches
Mail list logo
