Re: QueryParser in 3.x
On Fri, Sep 17, 2010 at 1:06 AM, Scott Smith wrote:
> I recently upgraded to Lucene 3.0 and am seeing some new behavior that I
> don't understand. Perhaps someone can explain why.
>
>
>
> I have a custom analyzer. Part of the analyzer uses the AsciiFoldingFilter.
> If I run a word with an umlaut through that analyzer using the AnalyzerDemo
> code in LIA2, as expected, I get the same word except that the umlauted
> letter is now a simple ascii letter (no umlaut). That's what I would expect
> and want.
>
>
>
> If I create a Queryparser using the call "new QueryParser(LUCENE_30, "body",
> myAnalyzer) and then call the parse() method passing the same word, I can see
> that the query parser has not removed the umlaut. The string it has is
> "+body: Europabörsen".
>
This seems to be an issue with your analyzer rather than with the
QueryParser. Since QueryParser didn't really change its behavior in
3.0 except of some default values. Can you provide more info what you
did with your analyzer? Did you try running the term with umlaut chars
through your Analyzer / Tokenstream directly? Something like that:
Analyzer a = new MyAnalyzer();
TokenStream stream = a.reusableTokenStream("body", new
StringReader("Europabörsen"));
TermAttribute attr = stream.addAttribute(TermAttribute.class);
while(stream.incrementToken())
System.out.println(attr.term());
simon
>
>
> I know I had to make a number of changes to the analyzer and the tokenizer to
> upgrade to 3.x. Is there something very different from the 2.x version that
> I'm likely missing.
>
>
>
> Anyone have any thoughts?
>
>
>
>
>
>
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: recommended way to identify a version to pass to StandardAnalyzer constructor?
Hey Bill, let me clarify what Version is used for since I think that caused little confusion. The Version constant was mainly introduced to help users with backwards compatibility and upgrading their codebase to a new version of lucene without breaking existing applications / indexes build with previous versions. For instance StandardAnalyzer preserves the positionIncrement in its StopFilter which was introduces in Lucene 2.9. If you use 2.4 and upgrade to 2.9 this change might break you app since you indexed with a 2.4 behavior. You phrasequeries might not work as expected anymore. If you don't have any upgrade issues or if you can simply reindex you might just use the latest version. Some usecases might require somewhat "buggy" behavior which has been fixed in various places in lucene but must be maintained because of backwards compatibility this is also done by Version. If a certain class like IndexWriter / IndexReader have maintained compatibility without a Version constant so there is no need to pass it to them. You will be implicitly on the latest version. Btw. you can also mix version as you like. hope that helps On Thu, Sep 16, 2010 at 11:39 PM, Bill Janssen wrote: > So, in version 3, I have to pass a version parameter to the constructor > for StandardAnalyzer. Since Version.LUCENE_CURRENT is deprecated, I'd > like this to be the same as the version of the index I'm using. Is > there a way of getting a value of Version for an index? I don't see > obvious methods on IndexReader and IndexWriter. > > Bill > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: Filtering times stored as longs in HEX
>From a quick look your code looks fine, but there are various possible reasons why you might not be getting the results you expect. http://wiki.apache.org/lucene-java/LuceneFAQ#Why_am_I_getting_no_hits_.2BAC8_incorrect_hits.3F Are the email and phone numbers stored as is, or analyzed? Does it work if you remove the date filter? Are the hex encoded strings the same length and in the right sequence? Posting a complete standalone test case or program, as small as you can make it while demonstrating the problem, can make it easier for people to spot problems. -- Ian. On Fri, Sep 17, 2010 at 3:39 AM, Todd Nine wrote: > Hi all, > I'm using Lucandra to index notes in our system. Since we can't use > numeric fields due to a bug in Cassandra (fixed in 0.7), I'm encoding > all times a epoch in Hex, then storing the hex string. I have the > following fields on my document. > > createdDate > phoneNumber > email > > > I want to perform a query where the input is either a phone number, or > an email. The user also passes in an epoch timestamp (long in > milliseconds), and the count. I need to return all documents with a > timestamp <= the given timestamp, and the maximum count. I'm having > some trouble building this query in my code. I never get any results, > but I can see the data is written to the index properly. Here is my > code. > > http://pastie.org/private/xzvnntmyjzxgpjgctxftrq > > > > Thanks, > Todd > > > > > - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Connection question
I'm trying to connect to a Lucene index on a test server. All of the examples that I've found use a local directory to connect into the Lucene index, but I can't find one that will remotely hook into it. Can someone please point me in the right direction? I'm fairly certain that someone has run into and fixed this problem, but I haven't been able to find a way to do it. Thanks for your help! -- Chris - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
RE: QueryParser in 3.x
First, let me say that I didn't think the problem was in QueryParser and I
apologize if that's how it sounded. QueryParser is a central method to Lucene.
1 of me having problems with QueryParser, 1000's of others not. Is the
problem more likely in my code or lucene. We'll all agree on the answer to
that question.
As further proof, I ran the following code. The first part is from Simon's
email (thanks for that snippet) and the second part is from LIA2.
// code from Willnauer email
Analyzer a = new MyAnalyzer(Version.LUCENE_30);
TokenStream stream = a.reusableTokenStream("body", new
StringReader("Europabörsen"));
TermAttribute attr = stream.addAttribute(TermAttribute.class);
while(stream.incrementToken())
{
System.out.println(attr.term());
}
// code from LIA2
stream = a.tokenStream("body", new StringReader("Europabörsen"));
TermAttribute term = stream.addAttribute(TermAttribute.class);
while (stream.incrementToken())
{
System.out.print(term.term());
}
The answer I got back was:
europabörsen
europaborsen
I realized the difference between these two was whether I was getting the
reusableTokeStream or the tokenStream. In looking at my code, the
ASCIIFoldingFilter was not in the filter setup for the resusableTokenStream().
It was for the tokenStream(). I added it to the reusableTokenStream and I now
get the result I wanted. The above code snippet generates the word without the
umlaut in both cases. So, problem solved.
Thanks to Simon for putting on the right track.
Scott
-Original Message-
From: Simon Willnauer [mailto:simon.willna...@googlemail.com]
Sent: Friday, September 17, 2010 1:03 AM
To: java-user@lucene.apache.org
Subject: Re: QueryParser in 3.x
On Fri, Sep 17, 2010 at 1:06 AM, Scott Smith wrote:
> I recently upgraded to Lucene 3.0 and am seeing some new behavior that I
> don't understand. Perhaps someone can explain why.
>
>
>
> I have a custom analyzer. Part of the analyzer uses the AsciiFoldingFilter.
> If I run a word with an umlaut through that analyzer using the AnalyzerDemo
> code in LIA2, as expected, I get the same word except that the umlauted
> letter is now a simple ascii letter (no umlaut). That's what I would expect
> and want.
>
>
>
> If I create a Queryparser using the call "new QueryParser(LUCENE_30, "body",
> myAnalyzer) and then call the parse() method passing the same word, I can see
> that the query parser has not removed the umlaut. The string it has is
> "+body: Europabörsen".
>
This seems to be an issue with your analyzer rather than with the
QueryParser. Since QueryParser didn't really change its behavior in
3.0 except of some default values. Can you provide more info what you
did with your analyzer? Did you try running the term with umlaut chars
through your Analyzer / Tokenstream directly? Something like that:
Analyzer a = new MyAnalyzer();
TokenStream stream = a.reusableTokenStream("body", new
StringReader("Europabörsen"));
TermAttribute attr = stream.addAttribute(TermAttribute.class);
while(stream.incrementToken())
System.out.println(attr.term());
simon
>
>
> I know I had to make a number of changes to the analyzer and the tokenizer to
> upgrade to 3.x. Is there something very different from the 2.x version that
> I'm likely missing.
>
>
>
> Anyone have any thoughts?
>
>
>
>
>
>
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: recommended way to identify a version to pass to StandardAnalyzer constructor?
Simon Willnauer wrote: > Hey Bill, > let me clarify what Version is used for since I think that caused > little confusion. Thanks. > The Version constant was mainly introduced to help > users with backwards compatibility and upgrading their codebase to a > new version of lucene without breaking existing applications / indexes > build with previous versions. For instance StandardAnalyzer preserves > the positionIncrement in its StopFilter which was introduces in Lucene > 2.9. If you use 2.4 and upgrade to 2.9 this change might break you app > since you indexed with a 2.4 behavior. You phrasequeries might not > work as expected anymore. If you don't have any upgrade issues or if > you can simply reindex you might just use the latest version. That's what I'm trying to do. But how? LUCENE_CURRENT is deprecated! How about adding a constructor for StandardAnalyzer that takes no parameters and is implicitly LUCENE_CURRENT? > Some usecases might require somewhat "buggy" behavior which has been > fixed in various places in lucene but must be maintained because of > backwards compatibility this is also done by Version. Sure. > If a certain > class like IndexWriter / IndexReader have maintained compatibility > without a Version constant so there is no need to pass it to them. You > will be implicitly on the latest version. Good. Bill - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: Connection question
Are you asking about network connections? There is no networking built into lucene. There is in solr, and lucene can use directories on networked file systems. -- Ian. On Fri, Sep 17, 2010 at 6:08 PM, Christopher Gross wrote: > I'm trying to connect to a Lucene index on a test server. All of the > examples that I've found use a local directory to connect into the > Lucene index, but I can't find one that will remotely hook into it. > > Can someone please point me in the right direction? I'm fairly > certain that someone has run into and fixed this problem, but I > haven't been able to find a way to do it. > > Thanks for your help! > > -- Chris > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: recommended way to identify a version to pass to StandardAnalyzer constructor?
On Fri, Sep 17, 2010 at 8:14 PM, Bill Janssen wrote: > Simon Willnauer wrote: > >> Hey Bill, >> let me clarify what Version is used for since I think that caused >> little confusion. > > Thanks. > >> The Version constant was mainly introduced to help >> users with backwards compatibility and upgrading their codebase to a >> new version of lucene without breaking existing applications / indexes >> build with previous versions. For instance StandardAnalyzer preserves >> the positionIncrement in its StopFilter which was introduces in Lucene >> 2.9. If you use 2.4 and upgrade to 2.9 this change might break you app >> since you indexed with a 2.4 behavior. You phrasequeries might not >> work as expected anymore. If you don't have any upgrade issues or if >> you can simply reindex you might just use the latest version. > > That's what I'm trying to do. But how? LUCENE_CURRENT is deprecated! > > How about adding a constructor for StandardAnalyzer that takes no > parameters and is implicitly LUCENE_CURRENT? We deprecated LUCENE_CURRENT for a good reason that is that folks will run into big trouble if they upgrade from X to X+n because behavior may change dramatically due to optimizations, bug fixes and useful features. If you blindly pass LUCENE_CURRENT you might end up with incompatible APIs in some cases (we do deploy "sophisticated backwards layers" like we did in CharTokenizer) or query analysis which will not work with you existing Version X index. What you should do is pick YOUR latest version manually and go through the changes once you upgrade. Write unittests for you API to make sure it does not break you code. Its worth the trouble! simon > >> Some usecases might require somewhat "buggy" behavior which has been >> fixed in various places in lucene but must be maintained because of >> backwards compatibility this is also done by Version. > > Sure. > >> If a certain >> class like IndexWriter / IndexReader have maintained compatibility >> without a Version constant so there is no need to pass it to them. You >> will be implicitly on the latest version. > > Good. > > Bill > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: QueryParser in 3.x
On Fri, Sep 17, 2010 at 7:34 PM, Scott Smith wrote:
> First, let me say that I didn't think the problem was in QueryParser and I
> apologize if that's how it sounded. QueryParser is a central method to
> Lucene. 1 of me having problems with QueryParser, 1000's of others not. Is
> the problem more likely in my code or lucene. We'll all agree on the answer
> to that question.
Don't worry :)
>
> As further proof, I ran the following code. The first part is from Simon's
> email (thanks for that snippet) and the second part is from LIA2.
>
> // code from Willnauer email
> Analyzer a = new MyAnalyzer(Version.LUCENE_30);
> TokenStream stream = a.reusableTokenStream("body", new
> StringReader("Europabörsen"));
> TermAttribute attr = stream.addAttribute(TermAttribute.class);
> while(stream.incrementToken())
> {
> System.out.println(attr.term());
> }
>
> // code from LIA2
> stream = a.tokenStream("body", new StringReader("Europabörsen"));
> TermAttribute term = stream.addAttribute(TermAttribute.class);
> while (stream.incrementToken())
> {
> System.out.print(term.term());
> }
>
>
> The answer I got back was:
> europabörsen
> europaborsen
>
> I realized the difference between these two was whether I was getting the
> reusableTokeStream or the tokenStream. In looking at my code, the
> ASCIIFoldingFilter was not in the filter setup for the
> resusableTokenStream(). It was for the tokenStream(). I added it to the
> reusableTokenStream and I now get the result I wanted. The above code
> snippet generates the word without the umlaut in both cases. So, problem
> solved.
>
> Thanks to Simon for putting on the right track.
you are using lucene 3.0? If so take a look at ReusableAnalyzerBase
which makes it much easier to build Analyzers and prevents code
duplication.
simon
>
> Scott
>
>
> -Original Message-
> From: Simon Willnauer [mailto:simon.willna...@googlemail.com]
> Sent: Friday, September 17, 2010 1:03 AM
> To: java-user@lucene.apache.org
> Subject: Re: QueryParser in 3.x
>
> On Fri, Sep 17, 2010 at 1:06 AM, Scott Smith
> wrote:
>> I recently upgraded to Lucene 3.0 and am seeing some new behavior that I
>> don't understand. Perhaps someone can explain why.
>>
>>
>>
>> I have a custom analyzer. Part of the analyzer uses the AsciiFoldingFilter.
>> If I run a word with an umlaut through that analyzer using the AnalyzerDemo
>> code in LIA2, as expected, I get the same word except that the umlauted
>> letter is now a simple ascii letter (no umlaut). That's what I would expect
>> and want.
>>
>>
>>
>> If I create a Queryparser using the call "new QueryParser(LUCENE_30, "body",
>> myAnalyzer) and then call the parse() method passing the same word, I can
>> see that the query parser has not removed the umlaut. The string it has is
>> "+body: Europabörsen".
>>
> This seems to be an issue with your analyzer rather than with the
> QueryParser. Since QueryParser didn't really change its behavior in
> 3.0 except of some default values. Can you provide more info what you
> did with your analyzer? Did you try running the term with umlaut chars
> through your Analyzer / Tokenstream directly? Something like that:
>
> Analyzer a = new MyAnalyzer();
> TokenStream stream = a.reusableTokenStream("body", new
> StringReader("Europabörsen"));
> TermAttribute attr = stream.addAttribute(TermAttribute.class);
> while(stream.incrementToken())
> System.out.println(attr.term());
>
> simon
>>
>>
>> I know I had to make a number of changes to the analyzer and the tokenizer
>> to upgrade to 3.x. Is there something very different from the 2.x version
>> that I'm likely missing.
>>
>>
>>
>> Anyone have any thoughts?
>>
>>
>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: Connection question
Yes, I'm asking about network connections. Are you aware of any documentation on how I can set up Solr to use the Lucene index that I already have? Thanks! -- Chris On Fri, Sep 17, 2010 at 3:02 PM, Ian Lea wrote: > Are you asking about network connections? There is no networking > built into lucene. There is in solr, and lucene can use directories > on networked file systems. > > > -- > Ian. > > > On Fri, Sep 17, 2010 at 6:08 PM, Christopher Gross wrote: >> I'm trying to connect to a Lucene index on a test server. All of the >> examples that I've found use a local directory to connect into the >> Lucene index, but I can't find one that will remotely hook into it. >> >> Can someone please point me in the right direction? I'm fairly >> certain that someone has run into and fixed this problem, but I >> haven't been able to find a way to do it. >> >> Thanks for your help! >> >> -- Chris >> >> - >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-user-h...@lucene.apache.org >> >> > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: recommended way to identify a version to pass to StandardAnalyzer constructor?
Simon Willnauer wrote: > On Fri, Sep 17, 2010 at 8:14 PM, Bill Janssen wrote: > > Simon Willnauer wrote: > > > >> Hey Bill, > >> let me clarify what Version is used for since I think that caused > >> little confusion. > > > > Thanks. > > > >> The Version constant was mainly introduced to help > >> users with backwards compatibility and upgrading their codebase to a > >> new version of lucene without breaking existing applications / indexes > >> build with previous versions. For instance StandardAnalyzer preserves > >> the positionIncrement in its StopFilter which was introduces in Lucene > >> 2.9. If you use 2.4 and upgrade to 2.9 this change might break you app > >> since you indexed with a 2.4 behavior. You phrasequeries might not > >> work as expected anymore. If you don't have any upgrade issues or if > >> you can simply reindex you might just use the latest version. > > > > That's what I'm trying to do. But how? LUCENE_CURRENT is deprecated! > > > > How about adding a constructor for StandardAnalyzer that takes no > > parameters and is implicitly LUCENE_CURRENT? > > We deprecated LUCENE_CURRENT for a good reason that is that folks will > run into big trouble if they upgrade from X to X+n because behavior > may change dramatically due to optimizations, bug fixes and useful > features. If you blindly pass LUCENE_CURRENT you might end up with > incompatible APIs in some cases (we do deploy "sophisticated backwards > layers" like we did in CharTokenizer) or query analysis which will not > work with you existing Version X index. Yes, but that's not an issue if I don't *have* existing version X indices, which I don't. > What you should do is pick YOUR latest version manually and go through > the changes once you upgrade. Write unittests for you API to make sure > it does not break you code. Its worth the trouble! Simon, this advice isn't helping. I have unittests, and, yes, they are worth the trouble. I always re-index my collection if I change to a different version of Lucene. So I'd like to make my choice of the value of org.apache.lucene.util.Version automatically, using tools, instead of choosing it manually, based on what version of Lucene the user has installed, and without encoding a limited set of strings in my application. How do I do that? More directly, is there any attribute or static method somewhere in Lucene which will return a value of org.apache.lucene.util.Version that corresponds to the version of the code? That's what I'm looking for. Version.LUCENE_CURRENT looks good, but it's deprecated. Or, is there a method which will take a Lucene version, expressed as a Package or perhaps even a string like "3.0.2", and return the appropriate Version value? If so, I could write my own code to retrieve the Lucene version, then call that method to retrieve the Version value. Bill - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: recommended way to identify a version to pass to StandardAnalyzer constructor?
Bill Janssen wrote: > ...is there any attribute or static > method somewhere in Lucene which will return a value of > org.apache.lucene.util.Version that corresponds to the version of the > code? That's what I'm looking for. Version.LUCENE_CURRENT looks good, > but it's deprecated. And, given that the sole purpose of this Version frob is to support the use of indices that were created with a different version of Lucene, it would be a very good thing to have methods on IndexSearcher, IndexReader, and IndexWriter (or perhaps simply on Directory?) which would allow a program to figure out what Version is appropriate for that index. Bill - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: Connection question
This can probably be done. The hardest part is cross-correlating your Lucene analyzer use with the Solr analyzer stack definition. There are a few things Lucene does that Solr doesn't- span queries for one. Lance On Fri, Sep 17, 2010 at 12:39 PM, Christopher Gross wrote: > Yes, I'm asking about network connections. > > Are you aware of any documentation on how I can set up Solr to use the > Lucene index that I already have? > > Thanks! > > -- Chris > > > > On Fri, Sep 17, 2010 at 3:02 PM, Ian Lea wrote: >> Are you asking about network connections? There is no networking >> built into lucene. There is in solr, and lucene can use directories >> on networked file systems. >> >> >> -- >> Ian. >> >> >> On Fri, Sep 17, 2010 at 6:08 PM, Christopher Gross wrote: >>> I'm trying to connect to a Lucene index on a test server. All of the >>> examples that I've found use a local directory to connect into the >>> Lucene index, but I can't find one that will remotely hook into it. >>> >>> Can someone please point me in the right direction? I'm fairly >>> certain that someone has run into and fixed this problem, but I >>> haven't been able to find a way to do it. >>> >>> Thanks for your help! >>> >>> -- Chris >>> >>> - >>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-user-h...@lucene.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-user-h...@lucene.apache.org >> >> > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > -- Lance Norskog goks...@gmail.com - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
How to close the wrapped directory implementation
With RAMDirectory we have the option of providing another Directory implementation such as FSDirectory that can be wrapped and loaded into memory: Directory directory = new RAMDirectory(FSDirectory.open(new File(fileDirectoryName))); But after building the index, if I close the IndexWriter then the data is still available for searches in the directory bean but nothing ever gets written to the disk! Is this a bug? Is there a workaround? Or is this by design? Is the RAMDirectory constructor only meant to read in data from the passed in argument? Or is it supposed to keep it around and update it when closing? Please write back, Thanks! - Pulkit - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
RE: Unexpected Results - using should and must in boolean query
: If you have some MUST terms, but you also want to have at least one of a : list of other terms (like 5 SHOULD clauses), the trick is to separate both: : Create a BooleanQuery with 2 MUST clauses, one is your required TermQuery : and the second clause is itself a BooleanQuery with all the SHOULD clauses. : This ensures that at least one of the SHOULD terms is needed together with : the MUST term. BooleanQuery.setMinimumNumberShouldMatch(1) has hte same effect on what is matched w/o requiring a nested BooleanQuery -- and because of the coord factor the scores from the single BooleanQuery will probably better represent your goal then using the nested BooleanQueries. -Hoss -- http://lucenerevolution.org/ ... October 7-8, Boston http://bit.ly/stump-hoss ... Stump The Chump! - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
RE: Unexpected Results - using should and must in boolean query
Hah, I forgot that, thanks! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Chris Hostetter [mailto:hossman_luc...@fucit.org] > Sent: Friday, September 17, 2010 7:21 PM > To: java-user@lucene.apache.org > Subject: RE: Unexpected Results - using should and must in boolean query > > > : If you have some MUST terms, but you also want to have at least one of a > : list of other terms (like 5 SHOULD clauses), the trick is to separate both: > : Create a BooleanQuery with 2 MUST clauses, one is your required TermQuery > : and the second clause is itself a BooleanQuery with all the SHOULD clauses. > : This ensures that at least one of the SHOULD terms is needed together with > : the MUST term. > > BooleanQuery.setMinimumNumberShouldMatch(1) has hte same effect on > what is matched w/o requiring a nested BooleanQuery -- and because of the > coord factor the scores from the single BooleanQuery will probably better > represent your goal then using the nested BooleanQueries. > > > > -Hoss > > -- > http://lucenerevolution.org/ ... October 7-8, Boston > http://bit.ly/stump-hoss ... Stump The Chump! > > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
