Chuck Williams wrote:
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.
Right, I think we'd add an "IndexWriter.abort()" method? Once you call that your IndexWriter has freed its state, released write lock, removed any files it had created, etc, but has not committed any changes to the index.
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?
One case I thought of is allowing optmize to "resume" from however far it had gotten if the first one hit disk full. I think the feeling here (from the feedback I've heard so far) is there aren't enough such cases to warrant separating commit from close and the small change to the index format?
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.
I think we'd just add a package protected IndexReader.open that takes SegmentInfos directly? IndexWriter would then pass in its (uncommitted) SegmentInfos. Or, if IndexWriter opens SegmentReaders directly (I think the patch for LUCENE-565 does currently) then this would not be necessary. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
