[jira] [Commented] (COUCHDB-1576) Allow deletions to expire after set time

["Dave Cottlehuber (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COUCHDB-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483970#comment-13483970 ] 

Dave Cottlehuber commented on COUCHDB-1576:
-------------------------------------------

Thanks Michel for reporting this. This is a consequence of using MVCC to enable straightforward replication and conflict handling API.

Are you aware of _revs_limit, a per-DB setting? It's not time-based but during compaction and replication this is taken into account:

http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options
http://wiki.apache.org/couchdb/Compaction/

Compaction is the way to recover that space, and for very active DBs the typical approach is to use a transactional DB and:
- either rotate them on a regular basis
- or aggregate to a separate metrics DB and re-create a fresh / empty DB regularly.

Is there an actual issue or barrier you're running into that won't be addressed by either compaction, or the transactional DB pattern?

                
> 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