incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Vander Stichele <svsam...@gmail.com>
Subject Re: change notifications question
Date Sat, 09 Apr 2011 08:43:28 GMT
On Fri, 2011-04-08 at 10:17 +1200, Dave Cottlehuber wrote:
> On 8 April 2011 05:43, Thomas Vander Stichele <svsamoht@gmail.com> wrote:
> > Hi everyone,
> >
> > I am adding change notification support to paisley (twisted library for
> > couchdb) and am writing a simple client that sends GUI notifications for
> > changed documents.
> >
> > While doing so, I was wondering if anyone ever considered having change
> > notifications not only notify the new rev id, but also the old one ?
> >
> > In my use case, after receiving a notification of a change, I now have
> > to request the new version, then request what I think is the previous
> > version (which I will have to do by asking for a list of revision id's -
> > since I don't know the previous revision) and then figuring out what was
> > the last one that wasn't mentioned in the change notification.
> >
> > These are three separate requests to be able to figure out changes in a
> > way to present them to the user (for example - was the task
> > added/completed/deleted ?)
> >
> > Any thoughts?
> >
> > Thomas
> 
> Thomas,
> 
> From an app perspective, I would be looking to see if the documents
> can be refactored to store the change as a separate doc, and use
> ?include_docs=true to pull the the prior version if required. This
> means one call to couchdb from the changes feed has the doc, the
> previous doc, and rev if you wish to push changes.
> 
> Does this simplify what you're trying to do in paisley itself?

Well...

Paisley is a library for CouchDB.  As such I don't think it should rely
on a specific structure of the documents in the database.  (Compare to
desktopcouch, where I think they make the same mistake - the nice
features of desktopcouch should be orthogonal to their desire of
enforcing a document structure).

Second, the 'couchdb way' pushes towards storing related data inside one
document, or more denormalized.  Currently best practices show how you
can do the equivalent of a single join, but that's it when it comes to
related data.  Your approach would mean that you'd get the current
'version' of something from a view instead of a simple get, and you
wouldn't be able to 'JOIN' to another type.  So the approach is very
limiting.

That is why I'm suggesting that it should be in fact couchdb providing
the necessary primitive for an app to figure out changes; ie, instead of
making the app figure out the revision of the document that was changed
before the change was made, simply pass it as an extra option in the
change notification.

Maybe I'm making the wrong point, or maybe I'm mistaken about the
couchdb way ? Feel free to tell me so.

Thomas


Mime
View raw message