couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: History Proposal
Date Sun, 16 Aug 2009 14:07:08 GMT

On 15 Aug 2009, at 19:02, Jason Davies wrote:

> On 6 Aug 2009, at 21:01, Brian Candler wrote:
>> On Thu, Aug 06, 2009 at 05:04:34PM +0100, Jason Davies wrote:
>>> The other good thing about storing historical
>>> versions as attachments is that they would get replicated.   
>>> Currently we
>>> don't replicate old MVCC versions, this would have to change as  
>>> well as
>>> preventing them from being compacted as you say.
>> However, we do replicate old MVCC versions if they are conflicting,  
>> and we
>> do keep them through compaction.
>> Perhaps "conflicting" and "historical" could be treated in roughly  
>> the same
>> way?
>> You resolve conflicts by deleting the conflicting rev(s). This  
>> could be done
>> for deleting historical versions too.
> Do we want deletions of historical versions to be replicated too?   
> For example, if I "permanently delete" a bunch of old versions on my  
> local machine, and then replicate to my master server, should the  
> master server also delete these old versions?  This would be  
> analagous to deleting conflicting revs.  I can see that in some  
> cases this may not be desired e.g. if someone is simply trying to  
> free up space, and they would prefer the master server to preserve  
> all revisions.

Is it possible to write a validate_doc_update function that would deny  
historical revision deletes from replicating? If yes, I'd say that's  
the answer for a server that is designated to keep all revisions.


View raw message