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:cc:content-type
         :content-transfer-encoding;
        b=OyNc5dprlEeushVOm3UiBJWFfN4219curl94CXbPaKewgdTPxqP+Bb/7dBW+yDkBcB
         wdWB0J9qsYsy5jNcnH+/65sqxXt6Kij7obcCGSz3Tlfsfu9bGwDMVET6xIF62AfWd0/L
         GeqISZj49LnRfVpDLFEEaPnJ6kESKV8oqJ3uo=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <4DC1B552.9040603@facilityone.com>
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>
	<4DC18FC7.10908@facilityone.com>
	<BANLkTikyOaVmrxdBwVwe8dSR_8=K06NejA@mail.gmail.com>
	<4DC1B552.9040603@facilityone.com>
Date: Thu, 5 May 2011 14:07:41 -0700
Message-ID: <BANLkTi=DEm04gmtX+AkfusKkBdKTGqE3gA@mail.gmail.com>
Subject: Re: Document Timestamp On Replication
From: Chris Anderson <jchris@apache.org>
To: user@couchdb.apache.org
Cc: wickedgrey@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Not sure I follow all the requirements, but here is what I've done in the p=
ast.

on page load: query the view with update_seq=3Dtrue

render the screen with up to date data as of seq X

open a changes request with since=3DX&include_docs=3Dtrue

each doc that comes down the pipe, run the map function again (in the
browser) and take whatever is emitted and stick it in your
datastructure that represents the view (or just directly update the
dom). also if an old version of the doc emitted something different,
remove whatever stuff in your in-page representation corresponds to
the old version of the doc.

now you have a screen that is kept up to date with a consistent
representation of what you'd get in a hard-reload, with a
transactional guarantee that no updates will be skipped.

Chris

On Wed, May 4, 2011 at 1:21 PM, Owen Marshall <omarshall@facilityone.com> w=
rote:
> On 05/04/2011 04:13 PM, Eli Stevens (Gmail) wrote:
>> 11:59 - Document D inserted on Node 2. =A0Replication hasn't happened ye=
t.
>> 12:00 - First access of view page 1 on Node 1. =A0Only A, B, C are prese=
nt.
>> 12:01 - D is replicated to Node 1.
>
> Mmm, yes, you're absolutely correct; depending on that view would carry
> with it the risk of an update race. It would (likely) work if replicates
> were consistently low-latency, but that's not a guarantee.
>
> Correct me if I'm wrong, but that view would work if:
>
> 1. you capture last_seq from _changes pre-view run
> 2. run the view, capturing the output
> 3. check _changes for any updates since=3Dyour captured last_seq
> 4. filter those IDs out of your captured view.
>
> Yuck.
>
> --
> Owen Marshall
> FacilityONE
> omarshall@facilityone.com | (502) 805-2126
>
>


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