Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 74.125.82.54 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=cjkPe3af+HIYA2f/Kh0v61gJlRrjHCG/I/t3CbumtNqCS/7dILNUCVvxg1ADGkseJM
         tQg988LxW/kv51yxIyTovyuBylIR3hNgUO/SGNDZJ4rVtgzr2kllWNgaNtt87ykkyAwD
         1nn+yDlBm4rCjN2G37BxtRko0mtzjgfFmHeZc=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <1304530508.22380.7.camel@mike.loop.com.br>
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>
	<2C4218CE-6352-4F06-9F23-38E77CFFB254@sri.com>
	<1304530508.22380.7.camel@mike.loop.com.br>
Date: Wed, 4 May 2011 12:17:09 -0700
Message-ID: <BANLkTi=AYrkvpxuuOj=9O=0VidJzcQm-qQ@mail.gmail.com>
Subject: Re: Document Timestamp On Replication
From: Chris Anderson <jchris@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This feature exists.

Query the view with ?update_seq=3Dtrue, and you will get a line in the
output that tells you what the DB seq the view is current as of.

Then you can subscribe to filtered changes with since=3D the seq, and
have a continuously updated transactional view of the view.

Cheers,
Chris

On Wed, May 4, 2011 at 10:35 AM, Mike Leddy <mike@loop.com.br> wrote:
> What you are describing could be resolved with a feature (that I believe
> does not exist).
>
> If you could supply a database sequence number when querying a view
> ie. return the results from the view when the database sequence number
> was "x" then the MVCC guarantees of couchdb would guarantee exactly
> what you want.
>
> Databases and views being append only pretty much resolves everything
> (unless a compact completes while you are still holding on to
> the sequence number).
>
> Regards,
>
> Mike
>
>
> On Wed, 2011-05-04 at 09:36 -0700, Jim Klo wrote:
>> I might be able to shed some light here, as I'm working w/ John on this =
project.
>>
>> Essentially I believe ultimately we need to be able to do is build a vie=
w that is similar to the _changes but filtered.
>>
>> Basically we need a way to maintain 'local' transactional integrity. =A0=
So assuming our Couch is busy receiving updates from other Couch nodes. =A0=
If we have a user that is querying a range against Couch that, lets has wou=
ld have 100,000 results. =A0We need to be able to paginate through that ran=
ge and be guaranteed that it's not going to be modified via some update hap=
pening in another thread.
>>
>> If you are familiar with OAI-PMH, essential we need to build flow contro=
l into the application, but if I request a range of objects at 12:00pm... I=
 need to be able to paginate through that range probably until 12:05pm, pot=
entially, without any updates between 12:00 and 12:05 effecting the result =
set.
>>
>> The idea about having the document with the local timestamp is that we w=
ould be able to create a view by timestamp to query in this manner.
>>
>> If you guys have alternate ideas on how we might achieve this - I think =
we'd be open to discussion.
>>
>>
>> Jim Klo
>> Senior Software Engineer
>> Center for Software Engineering
>> SRI International
>>
>>
>>
>>
>> On May 4, 2011, at 9:14 AM, Owen Marshall wrote:
>>
>> > On 05/04/2011 11:29 AM, Poyau, John wrote:
>> >> -We want to keep track of the time that a document is added/updated i=
n 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 pro=
ve
>> > 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 docume=
nt
>> > 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 ti=
me?
>> >
>> > --
>> > Owen Marshall
>> > FacilityONE
>> > omarshall@facilityone.com | (502) 805-2126
>> >
>>
>
>
>


--=20
Chris Anderson
http://jchrisa.net
http://couchbase.com