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.zol...@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 <awo...@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
