couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Poyau, John" <>
Subject Re: Document Timestamp On Replication
Date Wed, 04 May 2011 15:29:32 GMT

-----Original Message-----
From: Owen Marshall [] 
Sent: Wednesday, May 04, 2011 10:33 AM
To: Poyau, John
Subject: EXTERNAL: Re: Document Timestamp On Replication

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?

-We want to keep track of the time that a document is added/updated in a source database
-We want to keep track of the time that a document get replicated to a target databases on

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
* 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