Hi,
Finally, to "fix" it so it behaves like you may want it: just add a
MatchAllDocsQuery as MUST or SHOULD clause. You have full control on how it
behaves!
Uwe
Am November 6, 2020 6:05:03 PM UTC schrieb Nissim Shiman
:
> Thank You Erick and Adrien!
>On Friday, November 6, 2020, 08:43:59 AM E
Thank You Erick and Adrien!
On Friday, November 6, 2020, 08:43:59 AM EST, Erick Erickson
wrote:
Nissim:
Here’s a good explanation of why it was designed this way
if you’d like details:
https://lucidworks.com/post/why-not-and-or-and-not/
Don’t be put off by the Solr title, it’s really
Nissim:
Here’s a good explanation of why it was designed this way
if you’d like details:
https://lucidworks.com/post/why-not-and-or-and-not/
Don’t be put off by the Solr title, it’s really about
BooleanQuery and BooleanClause
Best,
Erick
> On Nov 6, 2020, at 8:17 AM, Adrien Grand wrote:
>
>
Hi Nissim,
This is by design: boolean queries that don't have positive clauses like
empty boolean queries or boolean queries that only consist of negative
(MUST_NOT) clauses don't match any hits.
On Thu, Nov 5, 2020 at 9:07 PM Nissim Shiman
wrote:
> Hello Apache Lucene team members,
> I have fo
Hi Patrick,
I don't think Lucene supports CNF or DNF for BooleanQuery?
BooleanQuery will try to do some rewriting simplifications for degenerate
cases, e.g. a BooleanQuery with a single clause. Probably it could do more
optimizing? It is quite complex already :)
Mike
On Tue, Sep 22, 2020 at 1
Ok! I will open an issue in JIRA then.
On Saturday, August 13, 2016 3:26 PM, Adrien Grand wrote:
The explanation makes sense, I think you're right. Even though I don't
think this optimization would be used often, it would certainly help
performance when it is used.
Le sam. 13 août 2016 à 12:21
The explanation makes sense, I think you're right. Even though I don't
think this optimization would be used often, it would certainly help
performance when it is used.
Le sam. 13 août 2016 à 12:21, Spyros Kapnissis a
écrit :
> Ok, I had some time to look a bit further into it. It seems that ind
Ok, I had some time to look a bit further into it. It seems that indeed a
SHOULD clause with FILTER is equivalent with an AND clause with a
minShouldMatch of -1 in terms of both the number of results and score.
My reasoning goes like this:
given:- a single clause both as a SHOULD and a FILTER is
I'm not awaken enough to figure out whether the -1 trick is right or not,
but if you manage to prove it somehow, patches to simplify boolean queries
at rewrite time are welcome!
Le mar. 9 août 2016 à 00:47, Spyros Kapnissis a
écrit :
> Hm, I hadn't really thought about the minShouldMatch part, I
Hm, I hadn't really thought about the minShouldMatch part, I thought it' d be
covered but I see your point being semantically different if you keep it as is.
However.. Running your edge case example on an actual local index I get the
following:
"(X X Y #X)" w/minshouldmatch=2 vs. (+X X Y) w/minsh
Off the top of my head, i think any optimiation like that would also need
to account for minNrShouldMatch, wouldn't it?
if your query is "(X Y Z #X)" w/minshouldmatch=2, and you rewrite that
query to "(+X Y Z)" w/minshouldmatch=2 you now have a semantically diff
query that won't match as many
I guess you're confusing it with MUST (MUST_NOT) logic. Try creating
the query you want to exclude without MUST_NOT and add it to the
BooleanQuery with MUST_NOT. That sounds very confusing.
For example
BooleanQuery bq = new BooleanQuery();
TermQuery tqwanted = new TermQuery(new Term("field1: lo
On Thu, Feb 3, 2011 at 5:57 PM, Phil Herold wrote:
> Hi,
>
>
>
> I'm getting incorrect search results when I use a MultiSearcher across
> multiple indexes with a Boolean query, specifically, foo AND !bar (using
> QueryParser). For example, with two indexes, I have a single document that
> satisfie
Thank you Grant. I will try your suggested approach. It confirms to me
that I wasn't lost too much;-)
mercibe
Grant Ingersoll a écrit :
On Mar 23, 2010, at 12:58 AM, Benoit Mercier wrote:
Hi,
I would like to write a query composed of a BooleanQuery (several clauses) and
a SpanQuery (Spa
On Mar 23, 2010, at 12:58 AM, Benoit Mercier wrote:
> Hi,
>
> I would like to write a query composed of a BooleanQuery (several clauses)
> and a SpanQuery (SpanNearQuery), where both are mandatory. Sounds simple
> but I have to work on spans returned by this query.
>
> I know that I could u
Well, you haven't run afoul of the usual suspects, that's pretty
clean timing code. I'm afraid I'll have to defer to the people who
know the internals of Lucene.
Best
Erick
On Sun, Dec 21, 2008 at 10:31 PM, Prafulla Kiran
wrote:
> Hi,
>
> Here's the code which I am using to time the query:
>
Hi,
Here's the code which I am using to time the query:
long startTime = System.currentTimeMillis();
TopDocCollector collector = new TopDocCollector(10);
is.search(query,collector);
ScoreDoc[] hits = collector.topDocs().scoreDocs;
long endTime = System.currentTimeMillis();
Most of the clauses w
What specifically are you measuring when you time the queries? I've been
mislead by including in my measurement say, creating the response. I realize
that throughput includes assembling the response, but the solution is
different
depending upon whether it's the actual search or what you do with the
Op Saturday 20 December 2008 15:23:43 schreef Prafulla Kiran:
> Hi Everyone,
>
> I have an index of relatively small size (400mb) , containing roughly
> 0.7 million documents. The index is actually a copy of an existing
> database table. Hence, most of my queries are of the form
>
> " +field1:value
http://wiki.apache.org/jakarta-lucene/LuceneFAQ#head-06fafb5d19e786a50fb3dfb8821a6af9f37aa831
--
Ian.
On Wed, Jul 23, 2008 at 12:26 PM, sandyg <[EMAIL PROTECTED]> wrote:
>
> Hi ALL,
>
> Please can u help how to overcome the exception
> org.apache.lucene.search.BooleanQuery$TooManyClauses: maxCl
Hi
It's pretty straightforward. Create a BooleanQuery and add other
queries to it e.g.
BooleanQuery bq = new BooleanQuery();
TermQuery tq = new TermQuery(new Term(k, v));
RangeQuery rq = new RangeQuery(new Term(k1, v0),
new Term(k1, v1),
Hi all,
Sorry for bothering again,
I am referring Lucene Documentation at
http://lucene.apache.org/java/docs/queryparsersyntax.html
that suggests
>> If you are programmatically generating a query string and then
parsing it with the query parser then you >>should seriously consider
building your
First time I tried this I made it WAY more complex than it is
WARNING: this is from an older code base so you may have to tweak
it. Might be 1.9 code
public class WildcardTermFilter
extends Filter {
private static final long serialVersionUID = 1L;
protected BitSet
Erick can you please point me to some example of creating a filtered wildcard
query. I have not used filters anytime before. Tried reading but still am
really not able to understand how filters actually work and will help me
getting rid of MaxClause Exception.
Regards,
Ruchika
Erick Eri
See below:
On Dec 1, 2007 1:16 AM, Ruchi Thakur <[EMAIL PROTECTED]> wrote:
>
> Erick/John, thank you so much for the reply. I have gone through the
> mailing list u have redirected me to. I know i need to read more, but some
> quick questions. Please bear with me if they appear to be too simple
Erick/John, thank you so much for the reply. I have gone through the mailing
list u have redirected me to. I know i need to read more, but some quick
questions. Please bear with me if they appear to be too simple.
Below is the code snippet of my current search. Also i need to get score inf
John's answer is spot-on. There's a wealth of information in the user group
archives that you should be able to search on discussing ways of providing
the functionality. One thread titled "I just don't get wildcards at all"
is one where the folks who know generously helped me out.
Once you find ou
Hi,
Your problem is that when you do a wildacrd search, Lucene expands the
wildacrd term into all possible terms. So, searching for "stat*"
produces a list of terms like "state", "states", "stating" etc. (It only
uses terms that actually occur in your index, however). These terms are
all adde
Thanks for the reply. Everything is working correctly now. I jumped the gun without debuging it
more. booleanANDSearch was not getting set correctly.
Erick Erickson wrote:
I don't see a problem with your booleanANDSearch thingy, although
I haven't tried it.
Does toString() return the same stri
I don't see a problem with your booleanANDSearch thingy, although
I haven't tried it.
Does toString() return the same string regardless of the value of
booleanANDSearch? That would surprise me. The default
is OR, so the toString output looks like booleanANDSearch is false.
In general, the Lucene
rick, the stock QP doesn't
quite do
what one (legitimately IMO) expects.
--Renaud
-Original Message-
From: Erick Erickson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 11:56 AM
To: java-user@lucene.apache.org
Subject: Re: BooleanQuery
These are not boolean operators, w
k Erickson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 11:56 AM
To: java-user@lucene.apache.org
Subject: Re: BooleanQuery
These are not boolean operators, which is often confusing. See the thread
"*Another problem with the QueryParser*"
for an exposition by Chris about
These are not boolean operators, which is often confusing. See the thread
"*Another problem with the QueryParser*"
for an exposition by Chris about how these operate. This may change what you
expect to come back from the parser... If it doesn't, then maybe someone
else can chime in ...
Erick
O
For:
BooleanQuery bQuery=new BooleanQuery();
bQuery.add(messageQuery,true,false)
Use:
BooleanQuery bQuery=new BooleanQuery();
bQuery.add(messageQuery, BooleanClause.Occur.MUST);
Mapping is as follows:
For add(query, true, false) use add(query, BooleanClause.Occur.MUST)
For add(query, false, fal
: >you can't have a boolean query containing only MUST_NOT clauses (which is
: >what (-(FILE:abstract.htm)) is. it matches no documents, so the mandatory
: >qualification on it causes the query to fail for all docs.
:
: This is true for the search queries, but it makes sense in a query
: filter I
Hi
you can't have a boolean query containing only MUST_NOT clauses (which is
what (-(FILE:abstract.htm)) is. it matches no documents, so the mandatory
qualification on it causes the query to fail for all docs.
This is true for the search queries, but it makes sense in a query
filter IMHO. I e
: In my mind this restriction only apply on a query with just a MUST_NOT
: clause and not to a composed query. I've wrong.
right ... it's an issue for any BooleanQuery, regardless of how that query
may be wrapped in other boolean queries.
-Hoss
--
In my mind this restriction only apply on a query with just a MUST_NOT
clause and not to a composed query. I've wrong.
thanks a lot,
Nicolas
: If I search with boolQuery, Lucene doesn't find anything.
: If I modify by hand the query from "+(-(FILE:abstract.htm))
: +(PATH:/bssrs)" to "-(FILE:
: If I search with boolQuery, Lucene doesn't find anything.
: If I modify by hand the query from "+(-(FILE:abstract.htm))
: +(PATH:/bssrs)" to "-(FILE:abstract.htm) +(PATH:/bssrs)", Lucene find
: the correct list of document.
:
: Does somebody know why ?
you can't have a boolean query containing
That worked... thanks!
-Original Message-
From: Michael D. Curtin [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 1:04 PM
To: java-user@lucene.apache.org
Subject: Re: BooleanQuery question
Van Nguyen wrote:
> I just want results that have:
>
> ID: 1234 OR 234
Van Nguyen wrote:
I just want results that have:
ID: 1234 OR 2344 OR 2323
LOCATION: A1
LANGUAGE: ENU
This query returns everything from my index. How would I create a query
that will only return results the must have LOCATION and LANGUAGE and
have only those three IDs.
I think you'll ne
Ok thanks a lot.
Before I use TermQuery for the filed doccotent now I use Query object with
QueryParser.parse and it's work perfectly.
-Original Message-
From: Gustavo Comba [mailto:[EMAIL PROTECTED]
Sent: 21 June 2006 16:00
To: java-user@lucene.apache.org
Subject: RE: Boolean
Hello,
I don't know how are you parsing your query, but may be the query you
are looking for is something like:
+(doccontent:avian doccontent:influenza) +doctype:AM
+docdate:[2005033122000 TO 2006062022000]
Regards,
Gustavo
-Mensaje original-
You should specify the field name for influenza as well.
Like this:
+doccontent:avian +doccontent:influenza +doctype:AM
+docdate:[2005033122000 TO
2006062022000]
Mile
-Original Message-
From: WATHELET Thomas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 2006 4:40 PM
To: j
Be careful, especially if you have some test data that you're using to prove
things out and only later will you use the "real" (and usually much larger)
data set. There are two problems that I know of with bumping the clauses to
MAX_VALUE.
1> you can run out of memory.
2> it might take a long time
Thanks friends. The problem was solved. I used
BooleanQuery.setMaxClauseCount(Integer.MAX_VALUE) because the value was
really big and so variable that I couldn't determine a consistent top
value.
--
Marim
Supriya Kumar Shyamal disse:
> Normally the default setup for BooleanCluase count is 1024, m
Normally the default setup for BooleanCluase count is 1024, may be your
query produce more query than 1024, one work around is that you set the
BooleanCluase count to more than 1024. You can do that by just invoking
the static method
BooleanQuery.setMaxClauseCount(2048);
supriya
Flávio Marim
On Mittwoch 19 April 2006 22:10, Flávio Marim wrote:
> I am a new Lucene user and I have been searching the group archives but
> couldn't solve the problem.
see
http://wiki.apache.org/jakarta-lucene/LuceneFAQ#head-06fafb5d19e786a50fb3dfb8821a6af9f37aa831
--
http://www.danielnaber.de
--
Jelda,
I have just added a patch for DisjunctionSumScorer.java here:
https://issues.apache.org/jira/browse/LUCENE-413 issue.
Could you try that patch and report the results at the jira issue?
In case you need help using the patch could you move the
discussion to the java-dev list?
Regards,
Paul
uesday, March 28, 2006 11:12 PM
> To: java-user@lucene.apache.org
> Subject: Re: BooleanQuery containing SpanNearQuery throws
> ArrayOutOfBoundsException .
>
> Comments inline below.
>
> On Tuesday 28 March 2006 18:29, Ramana Jelda wrote:
> >
> > Hi,
> > I
Comments inline below.
On Tuesday 28 March 2006 18:29, Ramana Jelda wrote:
>
> Hi,
> I have a got strange problem.
> My searchterm : "mp3 player"
> Lucene Query :
> +(
> +(
> spanNear([productName:mp, productName:3], 3, true)
> spanNear([subName:mp, subName:3], 3, true)
>)
> +(p
: > You mean Theoritically
: > RangeQuery should be forbidden because it always has potential time bomb ?
: > Should we comment it in javadoc ?
In my opinion, the only reason to use RangeQuery is if you are dealing
with very controlled ranges, where you know hte number of terms it will
expand to
Hello,
> >
> > : I upgade to 1.9.1 and reindexing
> > : I used NumberTool when I index the number.
> > :
> > : after upgrade I got following error when number range query.
> > : with query
> >
> > The possibility of a TooManyClauses exception has always existed with
> > RangeQuery and numbers, e
Hello
- Original Message -
From: "Chris Hostetter" <[EMAIL PROTECTED]>
To: "Lucene Users"
Sent: Tuesday, March 07, 2006 3:49 PM
Subject: Re: BooleanQuery$TooManyClauses with 1.9.1 when Number RangeQuery
>
> : I upgade to 1.9.1 and reindexing
> :
: I upgade to 1.9.1 and reindexing
: I used NumberTool when I index the number.
:
: after upgrade I got following error when number range query.
: with query
The possibility of a TooManyClauses exception has always existed with
RangeQuery and numbers, even when using NumberTool. Even if you neve
On 1 Nov 2005, at 08:17, Michael D. Curtin wrote:
tcorbet wrote:
I have an index over the titles to .mp3 songs.
It is not unreasonable for the user to want to
see the results from: "Show me Everything".
I understand that title:* is not a valid wildcard query.
I understand that title:[a* TO z
tcorbet wrote:
I have an index over the titles to .mp3 songs.
It is not unreasonable for the user to want to
see the results from: "Show me Everything".
I understand that title:* is not a valid wildcard query.
I understand that title:[a* TO z*] is a valid wildcard query.
What I cannot underst
On 1 Nov 2005, at 01:43, tcorbet wrote:
I have an index over the titles to .mp3 songs.
It is not unreasonable for the user to want to
see the results from: "Show me Everything".
I understand that title:* is not a valid wildcard query.
I understand that title:[a* TO z*] is a valid wildcard query
Sounds like a job for a Filter and CachingWrapperFilter (see
http://www.lucenebook.com/search?query=caching+filter ). Chris
Hostetter wrote a nice email about how he did this for C|Net maybe 1-2
weeks ago. Should be in the mailing list archives.
Otis
--- Jeff Rodenburg <[EMAIL PROTECTED]> wrote
2500 vs 84. Wow. That's quite a few OR statements I would be saving
following your guide of just indexing the parts of the datetime I plan
to search on. Every ms count.
Now I have a clear picture of how range query works. Great stuff. Thanks.
Btw, coming from a db background I'm so used to wri
On Jul 11, 2005, at 1:45 AM, [EMAIL PROTECTED] wrote:
Did a google serach on the problem when using the range search
phrase of "+datefield:[199801 TO 200512]" (date stored as
"MMDD") which returns 1 million hits.
error: org.apache.lucene.search.BooleanQuery$TooManyClauses
Adding "-Do
61 matches
Mail list logo
