[
https://issues.apache.org/jira/browse/LUCENE-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727620#action_12727620 ]
Yonik Seeley commented on LUCENE-1721:
--------------------------------------
bq. obviously, this is rather impractical as this would require opening a SegmentReader for each and every segment for each delete given the current implementation of handling deletes (causing this special delete to be extremely slow)
Right - seems better to be handled at the application level. Solr used to do it's own delete handling before switching to using Lucene's delete-by-term - something like that would give you more control.
bq. If the index only receives deletes that do not match the index, the application can be aware of this and prevent performing a commit (thereby removing the need for application specific cache loading/analytics/etc performed after a "noop" commit).
Sounds like you could perhaps use reopen() or the NRT (near realtime) patches - get a new reader, see what segments changed (if any).
> 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-unsubscribe@...
For additional commands, e-mail:
java-dev-help@...
