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
'{"/task/f6d5fe1b2a71eb0fdaddac0a72e10c39":
["1-f4f9a86eeb08a6a09b36a6f9bf81c2b1"]}'
There are revisions (2, 3, 4) in the db that I would expect to get returned.
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 <[email protected]
> > (mailto:[email protected])> wrote:
> > > 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 so:
> > >
> > > 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
