Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@www.apache.org Received: (qmail 29714 invoked from network); 20 Jul 2004 19:37:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 20 Jul 2004 19:37:49 -0000 Received: (qmail 48324 invoked by uid 500); 20 Jul 2004 19:37:43 -0000 Delivered-To: apmail-jakarta-lucene-user-archive@jakarta.apache.org Received: (qmail 48199 invoked by uid 500); 20 Jul 2004 19:37:43 -0000 Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Users List" Reply-To: "Lucene Users List" Delivered-To: mailing list lucene-user@jakarta.apache.org Received: (qmail 48185 invoked by uid 99); 20 Jul 2004 19:37:42 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [128.230.248.25] (HELO gwia201.syr.edu) (128.230.248.25) by apache.org (qpsmtpd/0.27.1) with SMTP; Tue, 20 Jul 2004 12:37:41 -0700 Received: from MTA2-MTA by gwia201.syr.edu with Novell_GroupWise; Tue, 20 Jul 2004 15:37:39 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.4 Date: Tue, 20 Jul 2004 15:37:35 -0400 From: "Grant Ingersoll" To: Subject: Re: lucene cutomized indexing Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N It seems to me the answer to this is not necessarily to open up the API, = but to provide a mechanism for adding Writers and Readers to the indexing/s= earching process at the application level. These readers and writers = could be passed to Lucene and used to read and write to separate files = (thus, not harming the index file format). They could be used to = read/write an arbitrary amount of metadata at the term, document and/or = index level w/o affecting the core Lucene index. Furthermore, previous = versions could still work b/c they would just ignore the new files and the = indexes could be used by other applications as well. This is just a thought in the infancy stage, but it seems like it would = solve the problem. Of course, the trick is figuring out how it fits into = the API (or maybe it becomes a part of 2.0). Not sure if it is even = feasible, but it seems like you could define interfaces for Readers and = Writers that met the requirements to do this. This may be better discussed on the dev list. >>> john.wang@gmail.com 07/20/04 11:28AM >>> Hi: I am trying to store some Databased like field values into lucene. I have my own way of storing field values in a customized format. I guess my question is wheather we can make the Reader/Writer classes, e.g. FieldReader, FieldWriter, DocumentReader/Writer classes non-final? I have asked to make the Lucene API less restrictive many many many times but got no replies. Is this request feasible? Thanks -John --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org=20 For additional commands, e-mail: lucene-user-help@jakarta.apache.org=20 --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-user-help@jakarta.apache.org