couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: document revisions
Date Sun, 14 Jun 2009 10:02:17 GMT

On 10 Jun 2009, at 22:31, Adam Wolff wrote:

> *bump* I guess I'm talking about #4 on the page referenced below --  
> storing
> off old document revisions. does that really make sense, or should I
> consider a couchdb extension to just preserve document revisions?

I prefer the making new docs for revisions pattern. When a write comes
in, I first make a copy of the current doc to a second "history" doc,  
and
then write the change over the original document.

Cheers
Jan
--


> A
>
> On Tue, Jun 9, 2009 at 8:47 AM, Zachary Zolton <zachary.zolton@gmail.com 
> >wrote:
>
>> You'll want to model your documents in terms of revisions.
>> For some ideas, see approaches 3 and 4 on this wiki page:
>> http://wiki.apache.org/couchdb/How_to_design_for_replication
>>
>> On Tue, Jun 9, 2009 at 10:33 AM, Adam Wolff <awolff@gmail.com> wrote:
>>
>>> Hi everyone,Our app needs to preserve document revisions. I know  
>>> that the
>>> revision feature of couchdb is not intended for application-level
>> document
>>> revisions, but the semantics of couch's revisions are perfect for  
>>> our
>> app,
>>> and I don't want to have to rebuild that feature. What's the best  
>>> way to
>>> take advantage of couch's built-in revisions? I know we can't rely  
>>> on the
>>> revisions being there, but they *are* there right after you write  
>>> a new
>>> version. After a successful write, the caller could be responsible  
>>> for
>>> putting a separate document for the old revision, right?
>>>
>>> Alternatively, is this a mod to couchdb that we should explore? A  
>>> feature
>>> so
>>> that you can say: for the documents in this database, preserve the
>>> revisions
>>> even upon compaction.
>>>
>>> Thoughts? Thanks,
>>> A
>>>
>>


Mime
View raw message