+1 Though not by docID (since they aren't reliable in context of IndexWriter)... and it should be undeleteDocuments (with an "s") since it could affect more than one doc.
Mike On Wed, Jul 29, 2009 at 10:55 AM, Shai Erera<ser...@gmail.com> wrote: > Hi > > I think such methods are useful for a Lucene app, which needs to rollback a > single document delete. Today, IndexReader offers undeleteAll(), which is a > bit extreme. There are two scenarios for this, that I know of: > 1) (recently showed up on the user list) I'd like to synchronize documents > on disk and in the index. So if I have a document in the index which I want > to delete, and also a file on the file system (corresponds to an ID or > something), and the file delete fails, I may want to undelete that document. > This has alternatives, but still and undeleteDocument will be useful in this > case. > > 2) ParallelReader allows one to add a document to two indexes, some fields > to one index and other to the second index, and then read those indexes in > parallel. Such applications will need to delete documents sometimes, and an > undeleteDocument will be useful if a "transactional delete" is needed: i.e., > if the first delete succeeds, and the second fails, undo the first delete. > > 3) ParallelReader doesn't support deleteDocument well currently - i.e., if > one of the deletes fail, some readers will be left w/ the document and some > won't (this is I think a bug). > > What do you think? > > Shai > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
