try;
-d '{"f6d5fe1b2a71eb0fdaddac0a72e10c39":
["1-f4f9a86eeb08a6a09b36a6f9bf81c2b1"]}'
the keys are the doc ids, not the relative url to the document.
B.
On 29 July 2011 18:05, Michael Aufreiter <[email protected]> wrote:
> 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
>
>
>
