Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 62109 invoked from network); 3 Apr 2002 15:44:40 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Apr 2002 15:44:40 -0000 Received: (qmail 9504 invoked by uid 97); 3 Apr 2002 15:44:40 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 9460 invoked by uid 97); 3 Apr 2002 15:44:40 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 9449 invoked from network); 3 Apr 2002 15:44:39 -0000 X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Searcher/Reader/Writer Management Date: Wed, 3 Apr 2002 17:43:52 +0200 Message-ID: <50EA669584662B498F13A5F24630A0C0DB16DD@peach.mnet.private> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Searcher/Reader/Writer Management Thread-Index: AcHbJA/ayKDmJ1Z/SUuxfI1DufSW9gAATY9g From: =?iso-8859-1?Q?Hal=E1csy_P=E9ter?= To: "Lucene Developers List" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > -----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 >=20 >=20 > > Yes, but then you rely on the user to make sure that they=20 > > don't create two > > on the same path, right? If you really don't like the static=20 > > style for some > > reason (why?), I suppose we could have a static accessor like: > > "IndexAccessControl getController(path)" and maintain an=20 > > internal map of > > controllers to avoid conflicts... >=20 > Oh, never mind. I kept missing the fact that the Analyzer is=20 > hard-coded > into the class. You're right, if we wanted to have a=20 > difference Analyzer > per path, we'd probably want to break it up... >=20 > Scott >=20 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=20 this is very similar to DataSource interface that has only one method = getConnection()=20 > > I suppose we could have a static accessor like: > > "IndexAccessControl getController(path)" and maintain an=20 > > 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: For additional commands, e-mail: