[
https://issues.apache.org/jira/browse/COUCHDB-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484056#comment-13484056
]
Robert Newson commented on COUCHDB-1576:
----------------------------------------
+1 from me on the idea, though expiration-based sets my spider sense
a-tingling. The _revs_limit feature is an explicit acknowledgment that keeping
historical knowledge forever, while theoretically require to fulfil the promise
of eventual consistency, is impractical.
Extending acknowledgement of that reality to long-deleted documents is a
similar idea. The danger, of course, is that should you purge too soon, your
set of replicas will never converge on the same state. So, for this to go
ahead, I'd like to hear how we can mitigate that, or make it obvious to users.
One thought is not to make this a local decision, but one of agreement between
a set of mutually replicating systems. An API endpoint that takes a list of
url's to couchdb databases which produces a list of the union of deleted
documents across them all, and purges them all. This might well be onerous but
it would be safe, assuming the list was comprehensive. An expiration-based
approach is potentially as good as this, as long as the expiration always
exceeds the time that the systems come back into synch, but potentially falls
short. Since there's no way to guarantee that two systems synchronize within a
given timeframe, I'm wary of having it trigger based on the local clock.
/ramble
> Allow deletions to expire after set time
> ----------------------------------------
>
> Key: COUCHDB-1576
> URL: https://issues.apache.org/jira/browse/COUCHDB-1576
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
> Affects Versions: 1.2
> Reporter: Michel Meyers
>
> Currently, CouchDB keeps all deletions forever. On a very active database
> this can lead to the number of deletions actually exceeding the number of
> active documents.
> Lotus Domino solves this by having a cut-off date after which deletion stubs
> are purged from a replica. It would be great to have a similar functionality
> in CouchDB, e.g. have a setting that determines how long deletion stubs are
> kept and then purges them from the local copy. Whether this setting resides
> in the DB design, and thus replicates everywhere, or possibly an INI setting
> for the local CouchDB instance is still to be determined.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
