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 Tue, 05 Jan 2010 05:21:27 GMT
On Mon, Jan 4, 2010 at 10:04 PM, Andreas Pavlogiannis
<paulogiann.couchdb@gmail.com> wrote:
> On 1/4/2010 10:58 AM, Chris Anderson wrote:
>>
>> 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.
>>
>
> I need to ensure that when creating a new
> document, its parent exists in the db.

If you drop this constraint, you should still be able to handle the
business case, while doing away with a bunch of complexity.


>
> Hm, what about the case in which  a user  has enough space to upload just
> one file, but several upload requests arrive concurrently. As these requests
> are handled locally, each one will allow for the document to be submitted.
> But in this way the user can exceed his quota unboundedly (extreme scenario,
> but possible).
>>

You can always handle uploads by setting a custom piece of data in the
validation function. if you run a view query to say what the users
free space is, you can use this to reject oversize attachment uploads.

Still, I'd rather accept all uploads, and initiate a billing system
action or something when they cross the threshold.



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message