I rarely submit but I've been seeing this sort of thing more and more on this board.
It seems that there is a need to treat Lucene as if it were a data storage or database like repository, where in fact it isn't. In our case, for large indexes we run either a parallel process to create the index or a nightly process. Always treating the index as a disposable lookup mechanism. When it comes to deleting items from an index, we simply just mark those items in a separate list or data structure and then filter them away until the index is refreshed the next go around. My point is, that it seems like folks want Lucene to act like a relational database when in fact it is not meant to be used that way. Perhaps I'm wrong and upgrades will allow for efficient deletions, but it has always been clear to me that Lucene is strictly an index and should be treated as a feature of your storage repository, i.e. database, file system, web, whatever. But not relied upon for that very storage or management of that storage. The deletion issue is true of almost any indexing engine I've used in the past, i.e. DT Search, Verity, etc. Am I missing something? For us it has been a "best practice" to treat Lucene as described. //andy On Fri, Aug 8, 2008 at 2:39 PM, Cam Bazz <[EMAIL PROTECTED]> wrote: > hello, > > what would happen if I modified the class IndexWriter, and made the delete > by id method public? > > I have two fields in my documents and I got to be able to delete by those > two fields, (by query in other words) and I do not wish to go trunk version. > > I am getting quite desperate, and if not found a solution I will have to > make my documents with 3 fields, a, b and a + b so I can delete by a and b. > > Best. > > could there be a side effect? > > Best. > > -c.b. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
