>"DynamicSortField", that would be perfect. Or i had to do:
>use IndexSearcher.search(Query query, int n) API to first filter out
>Top-n
>POIs and then do a manual sort after these n documents' StoredField's
>have
>all be loaded, which seems not efficient.
>
&
erty which cannot be
used by the SortField API, i doubt if Lucene can support a
"DynamicSortField", that would be perfect. Or i had to do:
use IndexSearcher.search(Query query, int n) API to first filter out Top-n
POIs and then do a manual sort after these n documents' StoredFie
Hi,
Tokenization is usually performed by a query parser before searching
and the result documents may include all terms or some of the terms or
only one term in the query string (it depends on your query
configuration).
> I'm trying to make sample search application with Lucene.
Have you checked
Hello.
I'm trying to make sample search application with Lucene.
search() method of IndexSearcher class searches documents with given query,
and returns TopDocs instance. TopDocs instance has array of ScoreDoc
instances.
My question is:
1. Will query be tokenized during search?
2. If so, does Sco
Thanks for the response and sorry for not updating the thread. issue turned
out to be not related to IndexSearcher.search() Further looking in the
code, found that the method was called multiple times. Issue resolved after
refactoring.
Thanks,
Kudret
On Thu, Mar 10, 2016 at 2:03 AM Adrien Grand
There is a lot of things happening under this method. Since it seems that
you ran this under a profiler, do you have a breakdown of which methods
this CPU time is spent in?
Le mar. 8 mars 2016 à 17:16, Kudrettin Güleryüz a
écrit :
> Hi,
>
> The code I am working on is spending long time in this
Hi,
The code I am working on is spending long time in this function:
Searcher.java:221 org.apache.lucene.search.IndexSearcher.search(Query, int,
Sort) 94400ms 95%
Query fed to the function looks ugly at first and I first thought that it
could be the culprit:
+body:/.*foo/ +((+dir1:foo +dir2:bar)
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
12:27 AM
> To: java-user@lucene.apache.org
> Subject: IndexSearcher.search(Weight weight, Filter filter, HitCollector
> results) is not there in 4.0 version
>
> We are using the following below method with Lucene 2.4.0
>
> public void search(Weight weight,
>Filter f
We are using the following below method with Lucene 2.4.0
public void search(Weight weight,
Filter filter,
HitCollector results)
throws IOException
We are upgrading to the latest version and looking at the API (4.0), the
above signature has been d
at warning).
Mike McCandless
http://blog.mikemccandless.com
On Fri, Jun 8, 2012 at 1:32 PM, Paul Hill wrote:
> I noticed today that my code calls
> IndexSearcher.search (Query query, Filter filter, Collector collector)
> But also noticed that the DOCs says
>
> "Application
I noticed today that my code calls
IndexSearcher.search (Query query, Filter filter, Collector collector)
But also noticed that the DOCs says
"Applications should only use this if they need all of the matching documents.
The high-level search API (Searcher.search(Query, Filter, int)
) is us
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
hen
I do a QueryParser.parse(queryString).
The BooleanQuery that I build up produces the following output:
String queryString = baseQuery.toString();
Output: +date_received:[20030301 TO 20090913] +type:O24337
+(site_domains_reversed:moc.rettiwt site_domains_reversed:moc.rettiwt.*)
Hits results = indexSearc
The BooleanQuery that I build up produces the following output:
String queryString = baseQuery.toString();
Output: +date_received:[20030301 TO 20090913] +type:O24337
+(site_domains_reversed:moc.rettiwt site_domains_reversed:moc.rettiwt.*)
Hits results = indexSearcher.search(baseQuery);
O
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
tch
- Original Message
> From: Cam Bazz <[EMAIL PROTECTED]>
> To: java-user@lucene.apache.org
> Sent: Monday, September 15, 2008 1:54:07 PM
> Subject: IndexSearcher.search
>
> Hello,
>
> What is the new favorable way of searching a query?
>
> I understand Hits
Hello,
What is the new favorable way of searching a query?
I understand Hits will be depreciated. So how do we do it the new way?
With hit collector?
Best.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-
28 matches
Mail list logo
