Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 209.85.160.56 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=jFBtvwXZvbVUPqJBptJ0gtg5UbtYpgF8+Sz2I+ORo64EAaCkN8GF4Ce33vWCag2D/T
         EXuZKmt/MAa3VqaQxhvnGKatIZ0khLh5pwI9OQYWBXF8hEdJX+QdIli/vYF+bMOxQ3k6
         AKNU1XEaGqLEm9UJ7XSczmxaIqoAMmXMNRv9Q=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <4B42D67D.2090401@gmail.com>
References: <4B42B68B.2070403@gmail.com>
	 <e282921e1001041058s23fe1170x3dcdcf4dcb914f33@mail.gmail.com>
	 <4B42D67D.2090401@gmail.com>
Date: Mon, 4 Jan 2010 21:21:27 -0800
Message-ID: <e282921e1001042121p1241ba9el73c3d43b1c39e3a0@mail.gmail.com>
Subject: Re: Dealing with Atomic Operations
From: Chris Anderson <jchris@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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> =A0wrote:
>>
>>>
>>> Hello,
>>>
>>> I 've been experimenting with Couchdb and I have reached a point in whi=
ch
>>> I
>>> need to do some transactions in an atomic way. I know that Couchdb lack=
s
>>> locking, so is there a uniform way to deal with this?
>>> In particular, I have created a filesystem in which each file and folde=
r
>>> 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 i=
s
>>> 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 =A0a user =A0has enough space to upload =
just
> one file, but several upload requests arrive concurrently. As these reque=
sts
> 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 scenar=
io,
> 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.


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