Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: 
 <82D2BB25EFABA3478B75FF11C88148D518D90531@mlnyb706mb.amrs.win.ml.com>
References: 
 <82D2BB25EFABA3478B75FF11C88148D518D90531@mlnyb706mb.amrs.win.ml.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <49B69A6C-8401-41EC-934D-7ECE9103E669@ehatchersolutions.com>
Content-Transfer-Encoding: 7bit
From: Erik Hatcher <erik@ehatchersolutions.com>
Subject: Re: Ideal Index Fragmentation
Date: Wed, 31 Aug 2005 12:24:40 -0400
To: java-user@lucene.apache.org


On Aug 30, 2005, at 9:53 PM, Friedland, Zachary (EDS - Strategy) wrote:
> More assorted questions:
>
> *    I have been reading the posts on using Filter vs.  
> BooleanQuery.  To implement a search-within-a-search, it seems the  
> Filter is advantageous due to its cacheability, but are there other  
> pros or cons that should be considered (memory, speed, etc).

It's only advantageous when the Filters are long-lived over multiple  
searches.  It's not really recommended for search-within-search when  
the initial search is transient.  Combining queries within a  
BooleanQuery is more recommended in that case.

> *    I'm interested in implementing a "dynamic filter" component  
> that will walk through the hits[] object and pull out distinct  
> values for certain fields to display as search-within-a-search  
> options (all of them will return at least one result since they are  
> in the hits[]).  Has anyone implemented something like this -- how  
> did it work out?

Walking all Hits and extracting a field is an expensive operation, so  
be forewarned on that.

> *    When using a ParallelMultiSearcher, is there an easy way to  
> know how many matches came from each index searched?  I'd like to  
> be able to display how many of each object are in the combined hits 
> [].  Since I'm storing one object type per index, the count of hits  
> from each index will give me that number.

I'm not sure if you can get at each indexes results in that way, but  
you can tell which index an individual hit came from (see API docs  
for details on that).

> *    Does anyone know when 1.9/2.0 will be released?

Your guess is as good as any at this point.  I'm not sure what is  
still left to be done for a 1.9 release.  I haven't heard any prods  
to release it any time soon, but you're welcome to push us to  
consider it if need be.

     Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org