Robert Muir commented on LUCENE-8198:

it looks reasonable. We should think about the name. I think "soft-delete" is 
the only real use-case, but it looks like it can do undelete too (assuming you 
store the fields etc). softUpdateDocument makes me think of freebsd filesystem 

+1 for multiple fields of updates. If you want to pay the price to keep deletes 
around longer than usual in the index, you may want to log some additional 
metadata (e.g. timestamp or user) that deleted it. At least timestamp is 
important if you want to have a mergepolicy that converts it into a real delete 
after say, 90 days, to match some retention policy or time-window to correct 

with your api, if doc is null it will just issue the delete with no replacement 

> Add ability to persist deletes across merges
> --------------------------------------------
>                 Key: LUCENE-8198
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8198
>             Project: Lucene - Core
>          Issue Type: Improvement
>    Affects Versions: 7.3, master (8.0)
>            Reporter: Simon Willnauer
>            Assignee: Simon Willnauer
>            Priority: Major
>         Attachments: LUCENE-8198.patch
> This allows conditionally persist deletes on a per document basis to prevent 
> them from being merged away. This expert feature is useful to maintain 
> history of documents in the index where otherwise a duplicate storage 
> mechanism would be needed. For instance features like CouchDBs changes API 
> can be build on top of persistent deletes. While using persistent deletes has 
> a considerably small overhead at merge time or when deletes applied to fully 
> deleted segments, there is no impact if persistent deletes are unused.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to