Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of john.poyau@lmco.com designates
 192.31.106.12 as permitted sender)
Date: Wed, 04 May 2011 12:32:00 -0400
From: "Poyau, John" <john.poyau@lmco.com>
Subject: RE: EXTERNAL: Re: Document Timestamp On Replication
In-reply-to: <4DC17B73.3010407@facilityone.com>
To: Owen Marshall <omarshall@facilityone.com>
Cc: "user@couchdb.apache.org" <user@couchdb.apache.org>
Message-id: <9946CE35511F1449ADF88A3F647DFE2816B07BEDD5@HVXMSP8.us.lmco.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Thread-Topic: EXTERNAL: Re: Document Timestamp On Replication
Thread-Index: AcwKdnq3FMIVpvIXTIab0aSTDEOkMwAAF3XA
Accept-Language: en-US
acceptlanguage: en-US
References: <9946CE35511F1449ADF88A3F647DFE2816B0602907@HVXMSP8.us.lmco.com>
 <4DC067DD.5070508@facilityone.com>
 <9946CE35511F1449ADF88A3F647DFE2816B06F1724@HVXMSP8.us.lmco.com>
 <4DC163B2.10502@facilityone.com>
 <9946CE35511F1449ADF88A3F647DFE2816B06F1FA1@HVXMSP8.us.lmco.com>
 <4DC17B73.3010407@facilityone.com>

Owen,

Thank you for all replies. I answered inline


-----Original Message-----
From: Owen Marshall [mailto:omarshall@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
omarshall@facilityone.com | (502) 805-2126