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 paulogiann.couchdb@gmail.com
 designates 209.85.219.216 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=J0JLq6KYWiLRQE4eRRgfRU45SMbupiFmgajKIz9ImiHcQ9aaY0cCy/MtsJ5dmMTTiJ
         806+zFbwpN96vhmGPozDwQXzAdNne9LU8FtGuocVofSLAT6td2yx6NHaUHCEVF/skpa2
         qpNINcq14f1DzptPHbsR/dKqyKv6nlIkQtvkg=
Message-ID: <4B42D67D.2090401@gmail.com>
Date: Mon, 04 Jan 2010 22:04:45 -0800
From: Andreas Pavlogiannis <paulogiann.couchdb@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: Dealing with Atomic Operations
References: <4B42B68B.2070403@gmail.com>
 <e282921e1001041058s23fe1170x3dcdcf4dcb914f33@mail.gmail.com>
In-Reply-To: <e282921e1001041058s23fe1170x3dcdcf4dcb914f33@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.
>    
Yes, this is the case. The idea is to store the full pathname in each 
document, so as to retrieve it in a single step. So when the user asks 
for the document 'root/home/foo/bar', I just return the document with 
that pathname, instead of  following the conventional pathname 
translation (first obtain root, then home etc..). The existence of 
folder documents is needed, as a user must have the ability to create 
folders, and possibly share them with other users. Given the above, I 
need to ensure that when creating a new document, its parent exists in 
the db. If not, the new document exists (and can be accessed) while, the 
branch it belongs to has been deleted.
> 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.
>    
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).
>
>    
>> 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.
>
>
>
>