i dont know if it can help, but i found that u can include local_seq=true in the view options, and that will expose doc._local_seq as the last change# of the doc. which eventualy can skip some steps below..
>..... > 1) GET changes to SourceDB. > 2) query view using ["metadata", changed.id] keys; which tells you > which rows in the ChainedDB need to be updated and which rows to grab > from this view. > 3) query reduced/grouped view using ["data", ...] keys from > previous step to get new values > 4) Bulk create/update/delete ChainedDB. > 5) Place secondary views on ChainedDB. > > Downsides: > * need to modify original map function (although a relatively > trivial substitution). > * need to modify original reduce function (although relatively > trivial insertion). > * As far as I can tell, no one has used this approach yet. > Untested. > > If no one has any better ideas, this is what I'll wind up trying. > > > It seems to me that a view changes feed would make this much > simpler. You could easily get the simplicity of the naive approach > with the speed of the incremental approaches. I thought I read about > a patch for view changes floating around, but some quick searching > didn't turn it up. Does it apply cleanly to 1.2 (or 1.3)? I'll > consider using it... but is there a reason it hasn't already been > accepted into master? > > > Thanks for reading this far, and thanks for any input you might have. > -- > Nick Evans
