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 thesunny@gmail.com designates
 209.85.198.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=DSYUTuUKFb1yx8YTcn+ypL4mQBy7FSn39ROoJcfvP1L55IKDobNulD3cX+WK13cAMV
         1tz8FNO4N8zbsvo1vA0aBFR4OuY0fxqNTUUjv0nZJh9PZfrQQA1BD7jkFXHDsS16rYEm
         imooG1ixySZZhYpFM37xNF/p7vbz62JhZ0AEE=
Message-ID: <518815b70901122020v51be8478t6ef2c482ba346dae@mail.gmail.com>
Date: Mon, 12 Jan 2009 20:20:33 -0800
From: "Sunny Hirai" <thesunny@gmail.com>
To: user@couchdb.apache.org
Subject: Re: Can I guarantee uniqueness in a field without using _id?
In-Reply-To: <6B1E25BD-C88A-4F24-8DFC-196B554514EC@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_79718_7687038.1231820433412"
References: <518815b70901111530o23f6ce31yb40f974ea85467c0@mail.gmail.com>
	 <25893274-A543-4F9A-9FE3-A8E93938051B@apache.org>
	 <518815b70901121417ldf0d691l2838488fd5684697@mail.gmail.com>
	 <e2111bbb0901121424i7904c0bemb68ff930da4a07f4@mail.gmail.com>
	 <518815b70901121505l2fd3fc21uab28dcdaf419103c@mail.gmail.com>
	 <20090113011256.GN11136@translab.its.uci.edu>
	 <D498A5BD-E298-422F-A46B-9E5150E33DE9@gmail.com>
	 <e282921e0901121855o362adf2t4caced3e46d6bd57@mail.gmail.com>
	 <6B1E25BD-C88A-4F24-8DFC-196B554514EC@gmail.com>

------=_Part_79718_7687038.1231820433412
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks for all the responses.

Just to clarify, I know that CouchDB is not relational and I know the
primary differences and limitations; however, I still have some questions if
you will permit.

While it could be noted as a weakness of my implementation, the other thing
to note is that _id can then no longer be used generically. For example, I
can not include a reference from another SQL database unless I make the
reference a very long String encoded with all the unique values which seems
to be a bad way to relate tables/databases.

Note that there is no way to handle two unique fields (e.g. "name" and
"email" both unique).

I know that CouchDB has different pros and cons from relational databases
and I'm okay with there being cons. I just want to make sure that what I'm
asking is (a) impossible to do because of the way CouchDB works or (b) a
design choice that is not constrained by CouchDB.

The reason I ask is that there appears to be some sort of a lock somewhere
to assure that you don't end up with two documents with the same id. For
example, if you PUT two new documents at exactly the same time in the same
server, one of them will fail because it will not have a "_rev". This is
actually an assertion, I'm not sure to be true.

I understand that two documents PUT into two different servers that
replicate the same database can conflict; however, can two of the documents
conflict in the same database?

If they CAN conflict, then the guaranteed uniqueness on a single server is
not actually guaranteed upon a successful insert. They can both "succeed"
but they can be in conflict. This could be bad for doing things like
creating a new user as two users can be granted the same name successfully
but only one actually gets it. In this case, the solutions to use _id to
guarantee a unique name can actually fail anyways, even though it may be
rare.

On the other hand, if _id CANNOT conflict within the same server, then it
appears there is some sort of lock somewhere. It might be very light, or
small, or whatever, but then there is a lock.

So, in other words, I would like to know which one is true:

A. there can be conflicts _id conflicts on the same server. In that case,
_id doesn't guarantee uniqueness in the sense that two records can be
inserted successfuly, but only one is authoritative. Then I have to deal
with this somehow anyways.

B. there aren't conflicts on the same server so you are guaranteed
uniqueness on the same server. The _id hack always works. In this case could
we not consider a similar situation to guarantee unique fields, perhaps in
the far (far) future? Even if not, I'd like to know that there can be no
conflicts on the same server.

C. Something else completely that allows both a conflict-free _id in a
manner that is simultaneously lock free that I haven't thought of.

Thanks for the feedback.

Sunny

------=_Part_79718_7687038.1231820433412--