couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Dealing with Atomic Operations
Date Mon, 04 Jan 2010 18:58:06 GMT
On Mon, Jan 4, 2010 at 7:48 PM, Andreas Pavlogiannis
<> wrote:
> Hello,
> I 've been experimenting with Couchdb and I have reached a point in which I
> need to do some transactions in an atomic way. I know that Couchdb lacks
> locking, so is there a uniform way to deal with this?
> In particular, I have created a filesystem in which each file and folder is
> represented by a single document, while its pathname is a list. For example:
> ['root', 'home']
> ['root', 'home', pictures']
> ['root', 'home', 'pictures', 'picture.jpg']
> Now, when creating the document with pathname ['root', 'home', pictures',
> 'my_dog.jpg'], I need to make sure that its parent, ['root', 'home',
> pictures'] exists in the db. Moreover, I need to ensure that the user is not
> exceeding his quota.

Why do you need the parent to exist? You can use views to create
parents "virtually." This way each file would have a path, and you
could use a view to sort all files so that those in paths and subpaths
together are listed together. There is no need for a document to
denote the existence of an empty directory.

If you need to model directory permissions, then it makes sense to
have a document for that directory, but this also doesn't seem like it
needs to be transactionally checked / modified with the creation of
new files.

The quota stuff seems like it doesn't need to be transactional. If a
user is over quota, they can't create new files. If they delete some
files to get below quota again, it seems ok if this is reflected
"eventually" instead of transactionally.

> The bulk update way would be ideal if  a possible conflict would create the
> appropriate error messages but as far as I know, that's not the case.
> Moreover, there are cases in which a bulk update seems inevitable (for
> example, when deleting a folder, so all its contents must be deleted too),
> but its poor behavior in a bad scenario (with document conflicts) makes it a
> bit difficult to use.
> Is there any way to circumvent all these problems?
> Is the behavior of the bulk updates going to change in the near future?

There are no plans to add transactional bulk updates as they are
incompatible with large partitioned clusters.

Chris Anderson

View raw message