couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregor Martynus <gre...@martynus.net>
Subject Re: Guys with deep knowledge about CouchDB Replication, I'd need your help :)
Date Tue, 02 Aug 2011 21:44:45 GMT
I had a look into data.js and its tasks example. I love the direction it's
heading to, great work!

I think the way you've implemented sync by posting all local document IDs
 is not very elegant though. I'm still new to Couch, but I think Couch makes
use of the _change feed for its replication and I think you should do it,
too.

For the »Tasks« example, I'd start by generating something like an
»account_id« (UUID) and then save each doc with an »account_id« attribute.
Then I'd ask for all changes since the last time I asked, filtered by this
»account_id«

Does that make sense?


On Mon, Aug 1, 2011 at 4:11 PM, Michael Aufreiter <ma@zive.at> wrote:

> Thanks. Will investigate that. However here's what I've got so far
> (involving localstorage):
>
> http://substance.io/#michael/offline-applications-with-datajs
>
> -- Michael
> On Tuesday, August 2, 2011 at 12:29 AM, Randall Leeds wrote:
> > On Fri, Jul 29, 2011 at 04:12, Michael Aufreiter <ma@zive.at (mailto:
> ma@zive.at)> 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.
> >
> > To solve replication and safely allow the application to be used
> > across tabs you need indexedDB because it has transactions.
> >
> > Let me break that deduction down:
> > Incremental replication requires a restart-able changes feed. A
> > changes feed requires an index of updates order by time/sequence
> > number. A sequence index that's kept in sync with the index of
> > documents ordered by name requires changes to two indexes in an atomic
> > transaction or race conditions are possible.
> >
> > If you're not worried about replicating incrementally or you're not
> > worried about the possibility of race conditions (e.g., concurrent
> > access by multiple tabs) you might be able to use LocalStorage,
> > otherwise you'll need IndexedDB.
> >
> > Since PouchDB aims to be a robust and general-purpose implementation
> > of CouchDB it uses IndexedDB.
> >
> > -Randall
> >
> > >
> > > 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 <ma@zive.at(mailto:
> ma@zive.at)> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message