[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
