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 <email@example.com
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.
firstname.lastname@example.org | (502) 805-2126