incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
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
<paulogiann.couchdb@gmail.com> 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
http://jchrisa.net
http://couch.io

Mime
View raw message