[
https://issues.apache.org/jira/browse/LUCENE-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727695#action_12727695
]
Tim Smith commented on LUCENE-1721:
-----------------------------------
That looks like its pretty close, and is definitely better than assuming the
index changed, but still not "exactly" what would be desired (at least by me).
looks IndexReader.reopen() will give a new IndexReader instance even if there
are no "actual" changes to the index (deletes/new segments) in the event that
some background merges were performed. This can result in a new IndexReader
being opened (via reopen()) even if no content changed. (while this will be a
more optimal search index, it will invalidate caches that will then need to be
reloaded)
a return status from commit would be more desirable
such a status could list the number new documents, deleted documents, and new
segments/merged segments, and so on
That way, an application could choose what criteria would facilitate opening a
new index
(this is going even more off topic though)
> IndexWriter to allow deletion by doc ids
> ----------------------------------------
>
> Key: LUCENE-1721
> URL: https://issues.apache.org/jira/browse/LUCENE-1721
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Shay Banon
>
> It would be great if IndexWriter would allow for deletion by doc ids as well.
> It makes sense for cases where a "query" has been executed beforehand, and
> later, that query needs to be applied in order to delete the matched
> documents.
> More information here:
> http://www.nabble.com/Delete-by-docId-in-IndexWriter-td24239930.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
