couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1576) Allow deletions to expire after set time
Date Thu, 25 Oct 2012 11:59:12 GMT


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.

> Allow deletions to expire after set time
> ----------------------------------------
>                 Key: COUCHDB-1576
>                 URL:
>             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:

View raw message