Features Download
From: Robert Newson <rnewson-1oDqGaOF3Lkdnm+yROfE0A <at> public.gmane.org>
Subject: Re: Guys with deep knowledge about CouchDB Replication, I'd need your help :)
Newsgroups: gmane.comp.db.couchdb.user
Date: Saturday 30th July 2011 16:00:59 UTC (over 6 years ago)

-d '{"f6d5fe1b2a71eb0fdaddac0a72e10c39":

the keys are the doc ids, not the relative url to the document.


On 29 July 2011 18:05, Michael Aufreiter 
> Trying to make use of _revs_diff for implementing my own replicator.
> I'm just wondering why I don't get a result for:
> curl -X POST localhost:5984/tasks/_revs_diff -d
> There are revisions (2, 3, 4) in the db that I would expect to get
> Basically I want to ask Couch: "Give me all the updates you have for a
certain set of id's (with the latest known revision)"
> Any ideas?
> -- Michael
> On Friday, July 29, 2011 at 1:12 PM, Michael Aufreiter wrote:
>> Nice. Having a look at it.
>> It really depends on how much functionality you wanna delegate to the
client. In my opinion, in most cases you wan't to keep the amount of local
data low. That's why I'll probably use localstorage to memoize a complete
snapshot of the current graph. Once you reload the page all data is loaded
into memory again (restored) and you can query it as usual (using
Data.Graph#find). So in my case I'd rather wanna use just LocalStorage
without employing indexedDB etc. as local views(map-reduce etc) wouldn't be
an requirement here. But what I need to solve is the replication thing.
>> On Thursday, July 28, 2011 at 6:18 PM, Max Ogden wrote:
>> > beginnings of an html5 couch: https://github.com/mikeal/pouchdb
>> >
>> > it would be great to get @mikeal and @tilgovi to chime in on this
>> > thread as they were writing the replicator for that
>> >
>> > On Thu, Jul 28, 2011 at 11:48 AM, Michael Aufreiter

>> > > I'm currently working on a complete data-persistence solution for
offline apps, involving CouchDB and Data.js. I already introduced Data.js
here at this mailing list the other day, but here's a link again:
>> > >
>> > > http://substance.io/#michael/data-js
>> > >
>> > > I've setup a cleanroom example (tasks) that I want to test the new
sync-functionality against.
>> > >
>> > > http://tasks.substance.io (don't miss
the sync button in the upper right corner)
>> > > https://github.com/michael/data/blob/7729d41677e48bd5132119997dc0cff53522bb55/examples/tasks/public/javascripts/views/app.js
>> > >
>> > > It's currently just one way. It just writes changes to the server
but does not pull in node-updates. Now this should change.
>> > >
>> > > The algorithm for a bi-directional sync I have in mind looks like
>> > >
>> > > 1. Pull: For all nodes I have in my local graph, check if there are
updates (other users might have updated them), and if yes, pull them in
>> > > If conflicts occur the client/user decides how to resolve it (choose
a revision or merge it)
>> > >
>> > > 2. Push: Write all local dirty nodes to the server
>> > >
>> > > If that succeeded, the sync is complete. Usually if there's not much
time between the pull and the push it's unlikely to run into conflicts when
doing the push.
>> > >
>> > > However I'm asking myself how CouchDB replication is implemented --
maybe I can re-use some of the concepts.
>> > >
>> > > In order to perform the Pull, I thought about sending a list of
ID's+revisions to the server. The server (resp. Couch) should then check if
there are updates for any of them. If yes, those nodes should be fetched
and delivered to the client. Given that number of ID/revision pairs, what
would be the best way to check for updates? Or do you have any other ideas
on how to do the pull?
>> > >
>> > > An implication of this scenario is that application developers
should do their best to keep the local graph rather small (the bigger it
gets the more overhead you have when doing the push, also more memory is
used). However this should suit a lot of scenarios (like in my case making
possible offline editing of Substance.io (http://Substance.io) documents)
>> > >
>> > > Would be great if some of you could help me out a bit here. I think
such a framework (Data.js+Couch) would be a great benefit for application
developers who wan't to build offline apps. What do you think?
>> > >
>> > > Thanks!
>> > >
>> > > -- Michael
CD: 4ms