1:01 AM
> To: java-user@lucene.apache.org
> Subject: RE: IndexSearcher.search(Weight weight, Filter filter, HitCollector
> results) is not there in 4.0 version
>
> Thanks.
>
> Can we use the following method in 4.0 as a replacement for the above
> method? However, we will
Thanks.
Can we use the following method in 4.0 as a replacement for the above
method? However, we will rewrite this to use FilteredQuery later but don't
want to refactor a lot.
public void search(Query query,
Filter filter,
Collector results)
throws IOException
ht
Hi,
the methods taking Weight are not for public use, only for internal use (e.g.
subclasses). You should not pass Weight to IndexSearcher, use the native Query
instance! Why do you want to pass a Weight to IndexSearcher?
Every Weight is created by a Query instance, so you can always pass the
I think that javadoc is stale; my guess is it was written back when
the collect method took a score, but we changed that so the collector
calls .score() if it really needs the score... so I can't think of why
that search method is inherently inefficient.
I'll fix the javadocs (remove that warning)
have been.
Thanks again.
-Original Message-
From: Mark Miller [mailto:markrmil...@gmail.com]
Sent: Monday, August 17, 2009 9:09 AM
To: java-user@lucene.apache.org
Subject: Re: IndexSearcher.search Behavior
Unfortunately, many Query's toString output is not actually parsable by
Q
Unfortunately, many Query's toString output is not actually parsable by
QueryParser (though some are). If you look at the result Query object
that gets built from the toString output, its likely different than the
BooleanQuery you are putting together.
--
- Mark
http://www.lucidimagination.
Thanks Chris,
It kinda makes sense to have control on what we do with the API, but for
first time users, it will be vital to have classes that will help them
smoothen their learning curve. By the looks of it, even advanced users use
Hits and are porting to TopDocs only because of the deprecation.
: We're not using TopDocCollector right now, as we're still using Hits.
: Performing some operation over every result is just one use case. We also
: have to deal with the user scrolling the display. Currently this works
: acceptably using the same java.util.List model for both cases. Sometimes
I really think Hits is definitely a nice utility class, when it comes to GUI
results presentation.
If we are to use our own class for this purpose, it wouldn't be much
different from Hits. Its a shame that we are drooping it.!
2008/9/19 Daniel Noll <[EMAIL PROTECTED]>
> Chris Hostetter wrote:
>
>
Chris Hostetter wrote:
But it don'treally see how it chagnes anything ... if your goal is to
perform an operating on every result in a set, why are you using
TopDocSCollector? why not write a HitCollector and perform your
operation in the collect method?
We're not using TopDocCollector rig
one moment:
the top doc collector is based on some sort of queue, I assume. What
kind of queue is that? does it sort based on score, or whichever doc
comes first.
best.
On Wed, Sep 17, 2008 at 9:43 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> : Well, it turns out the theoretical maximum f
: Well, it turns out the theoretical maximum for the Swing case is not
: Integer.MAX_VALUE, but is actually somewhere around 200 million due to
...
: In reality memory runs out sooner, which is why I was considering on-disk
: storage of the topdocs.
:
: But even if the user doesn't want t
Chris Hostetter wrote:
: Or do we make a replacement for TopDocCollector which doesn't have
this : drawback, and uses an alternative for PriorityQueue which
allows its array to : grow?
I don't see that as being much better -- you still wouldn't want to
pass MAX_INT because waht if there really a
: Related topic: what if we need all the hits and not just the first 100?
Solr has a FAQ related to this that i think also applies here..
>How can I get ALL the matching documents back? ... How can I return an
>unlimited number of rows?
>
>This is impractical in most cases. People typically onl
In cases where we dont know the possible number of hits -- and wanting
to test the new 2.4 way of doing things,
could I use custom hitcollectors for everything? any performance
penalty for this?
from what I understand both TopDocCollector and TopDocs will try to
allocate an array of Integer.MAX_V
Otis Gospodnetic wrote:
Hi,
Check the Hits javadoc:
* @deprecated Hits will be removed in Lucene 3.0.
* Instead e. g. [EMAIL PROTECTED] TopDocCollector} and [EMAIL PROTECTED] TopDocs}
can be used:
*
* TopDocCollector collector = new TopDocCollector(hitsPerPage);
* searcher.search(qu
Hi,
Check the Hits javadoc:
* @deprecated Hits will be removed in Lucene 3.0.
* Instead e. g. [EMAIL PROTECTED] TopDocCollector} and [EMAIL PROTECTED]
TopDocs} can be used:
*
* TopDocCollector collector = new TopDocCollector(hitsPerPage);
* searcher.search(query, collector);
* Scor
17 matches
Mail list logo
