couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kerr Rainey" <>
Subject Re: General Q about CouchDB
Date Wed, 17 Dec 2008 11:07:21 GMT
2008/12/17 Andrea Schiavini <>:
> In the second approach described in this article, posts are separated from
> comments. But isn't this in contrast with the impossibility of CouchDB to
> update atomically several documents? It could lead to a loss of database
> integrity, if in example an user deletes an article while another one
> updates a related comment. Shouldn't it be encouraged to keep related
> informations in the same document?

If you need / want to maintain consistency at all times in the
database you can't do it with CouchDB.  You need to let go of that
desire and focus on how things will work in practice.  There is no
referential integrity, so you can end up with orphaned documents.
Does this matter in practice?  How will it effect the application you
are writing?

In CouchDB you most definitely do not want to keep *all* related
information on the same document.  This leads to massive contention on
that document.  What if I have a blog post and attracts lots of
comments.  I don't want the users to keep having to resubmit there
comments because the main post is getting updated with other comments.
 The comment is related, but should not be part of the main post.  I
could also have two replicas of the post on different servers.  When
the post is replicated I don't want to have all the comments for one
version lost because they are part of the losing main post.  If they
are separate documents both replicas will just get new copies of the
comments from the other server.

So what happens if a user deletes a main post while a user is posting
a comment?  What will they see? Well, that depends on exactly what the
application layer does, but you should be able to engineer whatever
you would expect the same app backed by an RDBMS to do.  The user
submits their comment then gets redirect back to the main blog post.
That has been deleted and they see a message saying the post doesn't
exist.  In the backend there will be an orphan that will require
housekeeping to clean up.  The application will require some
housekeeping functionality so that I can delete all comments for a
blog post when I delete the main post.

Personally I would love to see so integrity checking and housekeeping
functions built in to CouchDB's core.  This wouldn't stop the database
getting into an inconstant state, but would provide provide automated
handling of common housekeeping tasks, like cascading deletes, so it
wouldn't have to be implemented ad nauseum at the application layer.


View raw message