couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Marshall <>
Subject Re: Document Timestamp On Replication
Date Wed, 04 May 2011 14:33:22 GMT
On 05/03/2011 04:54 PM, Poyau, John wrote:
> Thank you for your reply.  I am aware of the issue that you mentioned and that is why
I posted my question to list.
> One approach that I thought of is to use a separate document to hold the update_timestamp,

> these documents would not get replicated (filtered out on replication). Documents that
tracks the update_timestamp would get created using a document update handler as you mentioned.
> I posted my question looking to see if there were any another way to track document updates
even through replication. 

What exactly are you trying to accomplish? Why do you want to update
"update_timestamp" every time a document is replicated?

If you are just looking to track the time a document was updated, just
put an updated timestamp field on the document. When the user wants to
update a document, bump the timestamp at that time. Let CouchDB take
care of replicating the document. It's very good at that :)

If you want to handle conflicts (and you definitely should!) GET your
documents with conflicts=true. You can then look at the conflicting
documents and decide what to do. Options include:

* Picking the document with the biggest timestamp and discarding the
other one.
* POST a new update that merges the changes from both documents and has
a third and newer timestamp.
* Ask the user what to do!

Conflict resolution is very much up to you. Pick the one that makes the
most sense to your program. Either way, know that replication conflicts
*will* occur as a result of the multi-version concurrency model. But
conflicts are not bad, nor are they hard to handle.

The question you originally asked was how to update the timestamp _on
replication_. That's bad. Why do you want to do this? The only reason I
could think of is that you are trying to force some consistency across
nodes. Don't. CouchDB is very good at that. As a matter of fact, if you
ever think about layering your own synchronization on top of CouchDB,
you should immediately stop, because you won't be happy with the results.

Of course, if that's not what you want to accomplish, please correct me.

Owen Marshall
FacilityONE | (502) 805-2126

View raw message