couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Poyau, John" <john.po...@lmco.com>
Subject RE: EXTERNAL: Re: Document Timestamp On Replication
Date Wed, 04 May 2011 16:32:00 GMT
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


Mime
View raw message