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 robert.newson@gmail.com
 designates 74.125.82.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=CD3vfXrDmAw6qVqetwNrb00gscBemAAIusk1U2suBvWBWvVrXZviaRq+ffroobvW4h
         6aXR6MwlWrfZaXrVyFs8a9sdiEdsd9TH/1CKOTM6PYwuYD+pT2i6KD344CqZiZl1Wb1e
         ZXkKJUFfunNi9fm9VBpzMDWve9vX4UVywv8iQ=
MIME-Version: 1.0
In-Reply-To: <BC6010D7-C349-4933-8B80-D75EF50ECC31@gmail.com>
References: <f39928a61003271656pc4dac64k8af7d06575af7b15@mail.gmail.com>
	 <91076E76-9FAB-4590-82E2-9B14563882F0@gmail.com>
	 <f39928a61003271712n4969491dkee1d3ed9543aa710@mail.gmail.com>
	 <A204A077-4405-490F-A916-62013DE64B5F@apache.org>
	 <f39928a61003272041m31be57a3ncee7e9cb696a78b8@mail.gmail.com>
	 <6878DAF8-B582-4D83-AD33-2F590CB27313@apache.org>
	 <f39928a61003280140p78016c1bq9113c71fb25a8601@mail.gmail.com>
	 <09606748-C03F-4C89-A7B4-694F8D91F5A0@gmail.com>
	 <46aeb24f1003280540k3af9ce40j4bdc237aa46cbeb0@mail.gmail.com>
	 <BC6010D7-C349-4933-8B80-D75EF50ECC31@gmail.com>
Date: Sun, 28 Mar 2010 14:43:34 +0100
Message-ID: <46aeb24f1003280643r4ee7790du15b16ae328ac120d@mail.gmail.com>
Subject: Re: Validate uniqueness field
From: Robert Newson <robert.newson@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

"not every application requires to be extremely distributed" -- for
everything else, there's CouchDB. :)

I completely agree that not every application needs to be distributed.
For applications that are relational in shape, it makes sense to use a
relational database solution. Conversely, for something very
relational, it makes no sense to use a non-relational database
solution.

If you need multi-document transactions, multiple constraints and
don't need to be distributed, don't need to shard, and don't need
offline replication, it's not clear that CouchDB is a good fit. On the
other hand, if your application is a natural fit for CouchDB, then
you'll also be able to scale up when needed.

Bulk update used to work in the way you are suggesting and this
behavior was removed because it cannot work the same way when you
replicate or shard. I suspect that trend will continue rather than
reverse.

B.

On Sun, Mar 28, 2010 at 2:03 PM, Alexander Uvarov
<alexander.uvarov@gmail.com> wrote:
> Not every document requires locking. Also, not every application requires=
 to be extremely distributed. Developers can make a decision what kind of a=
pplication is cooking, in other words, should it scale to thousands of node=
s, or just single master with many readers would pretty good.
> The same about transactions, offline replication not ever required. An op=
tion to reject on conflict during bulk update would be really helpful (just=
 use single master), but there are obvious problems with sharding coming :(=
.
>
> On 28.03.2010, at 18:40, Robert Newson wrote:
>
>> "I am wondering why not introduce locking in couchdb"
>>
>> It's because locking doesn't scale. The locking strategy you outlined
>> works fine when your database runs on one machine, but fails when it
>> runs on two or more machines. A distributed lock, while possible,
>> would require all machines to lock, which requires them all to be up,
>> and, of course, ten machines are then no faster than one machine. Most
>> distributed locking protocols are blocking (like the usual 2PC
>> protocol), the non-blocking ones are either more overhead (3PC) or
>> more complex (Paxos).
>>
>> CouchDB doesn't let you do with one machine that which won't work when
>> you have ten machines. It's quite deliberately not letting you do
>> something that won't scale.
>>
>> B.
>>
>> On Sun, Mar 28, 2010 at 1:33 PM, Alexander Uvarov
>> <alexander.uvarov@gmail.com> wrote:
>>>
>>> On 28.03.2010, at 14:40, faust 1111 wrote:
>>>
>>>> Its sounds like pair of crutches ;)
>>>
>>> Agree with you. Lack of uniqueness, lack of transactions makes couch co=
mpletely useless for most cases. Solutions like multiple docs with _id as u=
nique key, along with "inventory tickets" sounds insane.
>>>
>>> I invented simple solution with Redis. Just an idea. You can use Redis =
setnx, msetnx operations to lock desired documents, or just lock "User" by =
giving this string as key in Redis to lock whole User type. Then just try t=
o lock "User", create your User document, unlock. If there is already a loc=
k, wait and try again. But deadlocks are possible when process that owned t=
he lock is dead and no one can release a lock.
>>> Redis commands: http://code.google.com/p/redis/wiki/MsetCommand
>>>
>>> I am wondering why not introduce locking in couchdb. Couchdb is designe=
d to be extremely fast, but there are also real world problems. Awesome tec=
hnology, I am crying that such restrictions taking it away.
>
>