couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Document Timestamp On Replication
Date Thu, 05 May 2011 21:07:41 GMT
Not sure I follow all the requirements, but here is what I've done in the past.

on page load: query the view with update_seq=true

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

open a changes request with since=X&include_docs=true

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.


On Wed, May 4, 2011 at 1:21 PM, Owen Marshall <> wrote:
> On 05/04/2011 04:13 PM, Eli Stevens (Gmail) wrote:
>> 11:59 - Document D inserted on Node 2.  Replication hasn't happened yet.
>> 12:00 - First access of view page 1 on Node 1.  Only A, B, C are present.
>> 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=your captured last_seq
> 4. filter those IDs out of your captured view.
> Yuck.
> --
> Owen Marshall
> FacilityONE
> | (502) 805-2126

Chris Anderson

View raw message