lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Halácsy Péter <halacsy.pe...@axelero.com>
Subject RE: Searcher/Reader/Writer Management
Date Wed, 03 Apr 2002 15:43:52 GMT


> -----Original Message-----
> From: Scott Ganyo [mailto:scott.ganyo@eTapestry.com]
> Sent: Wednesday, April 03, 2002 5:30 PM
> To: 'Lucene Developers List'
> Subject: RE: Searcher/Reader/Writer Management
> 
> 
> > Yes, but then you rely on the user to make sure that they 
> > don't create two
> > on the same path, right?  If you really don't like the static 
> > style for some
> > reason (why?), I suppose we could have a static accessor like:
> > "IndexAccessControl getController(path)" and maintain an 
> > internal map of
> > controllers to avoid conflicts...
> 
> Oh, never mind.  I kept missing the fact that the Analyzer is 
> hard-coded
> into the class.  You're right, if we wanted to have a 
> difference Analyzer
> per path, we'd probably want to break it up...
> 
> Scott
> 

That's why I've written that finally the interface is:
public interface IndexAccessControl {
	public Searcher getSearcher();
	public IndexWriter getWriter(boolean create);
	pubic IndexReader getReader();
}

I'd like to use two implementation:
a. Avalon component: class of analyzer, mergeFactory, maxDocs etc. can be configured by XML
elements
b. simple implementation where this properties can be set by setter methods 

this is very similar to DataSource interface that has only one method getConnection() 

> > I suppose we could have a static accessor like:
> > "IndexAccessControl getController(path)" and maintain an 
> > internal map of
> > controllers to avoid conflicts...
yes, this is a good way as far as the "not Avalon implementation" is concerned

peter



--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message