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 16:14:43 GMT
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

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.

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

What problem do you think you are solving by storing the replicated time?

Owen Marshall
FacilityONE | (502) 805-2126

View raw message