I don't see how to do commits without at least some new methods. There needs to be some way to roll back changes rather than committing them. If the commit action is IndexWriter.close() (even if just an interface) the user still needs another method to roll back.
There are reasons to close an IndexWriter other than committing changes, such as to flush all the ram segments to disk to free memory or save state. We now have IndexWriter.flushRamSegments() for this case, but are there others? As was already pointed out to delete documents you have to find them, which may require a reader accessing the current snapshot rather than the current checkpoint. There needs to be some way to specify this distinction. Chuck Yonik Seeley wrote on 01/17/2007 06:48 AM: > On 1/17/07, Michael McCandless <[EMAIL PROTECTED]> wrote: >> If this approach works well we could at some point deprecate the >> delete* methods on IndexReader and make package protected versions >> that IndexWriter calls. > > If we do API changes in the future, it would be nice to make the > search side more efficient w.r.t. deleted documents... at least remove > the synchronization for isDeleted for read-only readers, and perhaps > even have a subclass that is a no-op for isDeleted for read-only > readers. > > -Yonik > http://incubator.apache.org/solr Solr, the open-source Lucene search > server > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
