Owen,

Thank you for all replies. I answered inline


-----Original Message-----
From: Owen Marshall [mailto:omarsh...@facilityone.com] 
Sent: Wednesday, May 04, 2011 12:15 PM
To: user@couchdb.apache.org
Cc: Poyau, John
Subject: EXTERNAL: Re: Document Timestamp On Replication

On 05/04/2011 11:29 AM, Poyau, John wrote:
> -We want to keep track of the time that a document is added/updated in 
> a source database

Then you definitely want an updated field per-document.

Implementing this varies with your needs. You could use a single timestamp that 
gets clobbered each time, if you don't need a huge auditing trail. You could 
also do a list of timestamps if it would prove helpful.

One other technique that I'm especially fond of is to store changes as 
attachments to each document. This gives you great audit trails -- who made 
what change when. You could go so far as to store the full document state 
before the change.

But if you don't need that level of auditing, a timestamp field is the way to 
go.

> -We want to keep track of the time that a document get replicated to a target 
> databases on replication.

Don't. Don't don't don't.

But because I hate it when the answer is "you're doing it wrong" and nothing 
else, some notes:

* You will definitely want to separate the replication time from the update 
time (as they clearly aren't the same thing.)

* Further, that *cannot* go in the document, clearly.
I know, I was planning on using a separate document to track update_timestamp.

* You'd need at a minimum filtered/named replication to send the documents you 
want, and an update handler to put the "replicated time"
in some other document.


Again though, you never answered the simple question of *why* you want to know 
this. Let me be clear: what you are trying to do adds a bunch of complexity to 
your documents, your replication, and your program. And I'm not sure why you 
want to do it so badly.

I am implementing a spec that requires a update_timestamp that tracks the time 
any change to the document including when it is replicated to a target db.  I 
think you make a good point that an update_timestamp is not exactly the same as 
the replication_timestamp.

What problem do you think you are solving by storing the replicated time?
Knowing when the document was added the target database
--
Owen Marshall
FacilityONE
omarsh...@facilityone.com | (502) 805-2126

Reply via email to