Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of kevin.r.coombes@gmail.com
 designates 209.85.214.180 as permitted sender)
Message-ID: <4F2AAF24.9010907@gmail.com>
Date: Thu, 02 Feb 2012 09:43:32 -0600
From: "Kevin R. Coombes" <kevin.r.coombes@gmail.com>
Organization: UT M.D. Anderson Cancer Center
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: dev@couchdb.apache.org
CC: Robert Newson <rnewson@apache.org>
Subject: Re: Unique instance IDs?
References: 
 <CAJ_m3YDdwGpCGoOZX1xVmzguOw4LEa+n100mssAbCL2NxzhFbw@mail.gmail.com>
 <CAN-3CB+w5xdJOTUBvQYu2Z08BXryxoC-_NsGc=coJUdBUTothg@mail.gmail.com>
 <CAJ_m3YBa7zOd+tAAMqN5Y6nEjH_Q6DwGqjS6ZwXypABa39ZTNg@mail.gmail.com>
 <CAN-3CBLjumu5pRhLO4ZKkMpRQWMoTiUBaX2eR_38LwQ1=9wxyQ@mail.gmail.com>
 <CAJ_m3YC4mK4ateUbquExUjVKjKFyGMU=K_YcpYvhuQFiefjOCA@mail.gmail.com>
 <CAN-3CB+ChyCBR=r+sBXBCMqsD=dENdq7ivUQZoM2ubYTFOQjEA@mail.gmail.com>
 <CAJ_m3YAAwj8yVp_MnHDUk9oGo7ekgzxDqGEXiwQ+9u01hv6-zw@mail.gmail.com>
 <4EE72C0E.4080704@googlemail.com> <20111214225204.GC11299@atypical.net>
 <CAAL6JQivN+E9oqU1wPG-ifz=M+i-DwCjgX6DHmSEikw7_QJptA@mail.gmail.com>
 <20111215021017.GB25751@atypical.net>
 <CA+Y+445C_tm_BJ3F4p=kX5RqnVP0BJeMDow5+0rLz91j4MO5xg@mail.gmail.com>
 <4F2AA097.3020202@gmail.com>
 <CABvT1DGOPf7WPMSCxmmPsbKpZx+vYerQOq8V0+5enXe4Tv+Vwg@mail.gmail.com>
In-Reply-To: 
 <CABvT1DGOPf7WPMSCxmmPsbKpZx+vYerQOq8V0+5enXe4Tv+Vwg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I don't think it's such a slam-dunk, but maybe I'm guilty of a 
goal-tending violation.

It depends on whether you intend to keep replicating the two copies to 
keep them synchronized.  If you want that (and most of the time, I do), 
then I think it's an advantage to keep the same "UUID".  The (matching) 
internal UUIDs indicates that you think of these two things as the same 
abstract entity.  The full URL distinguishes the "physical" copies.

If on the other hand, you expect the copies to evolve into something 
differently over time, then I can see how you might want different 
UUIDs.  But again, the full, easy-to-construct URL distinguishes them.

As far as I can tell, the existing system still lets you have it both 
ways....

On 2/2/2012 8:45 AM, Robert Newson wrote:
> ... until you copy the database (and its uuid) and have two databases
> with the same uuid. This has always been the slam-dunk argument
> against database uuid's.
>
> B.
>
> On 2 February 2012 09:41, Kevin R. Coombes<kevin.r.coombes@gmail.com>  wrote:
>> For CouchDB, I think UUIDs are clearly the way to go.  After all, given the
>> UUID, database,  and hostname, you can construct the desired URL directly by
>> forming
>>     http://hostname:5984/database/UUID
>> As Noah points out, if you used this entire URL as the identifier (by which
>> I assume he means the _id field), then you would lose the ability to copy
>> the document elsewhere.  This would, of course, break replication
>> completely.
>>
>> Keeping the UUIDs as they are gives the best of both worlds.  Easy
>> replication, and (as long as the database is hosted at the same place) an
>> easy way for humans and programs to construct stable URIs or URLs that point
>> to each document.
>>
>>     -- Kevin
>>
>>
>> On 1/22/2012 12:44 PM, Noah Slater wrote:
>>> Sorry to bump this old thread, but just going through my backlog.
>>>
>>> With regard to URLs, I think there is some confusion about the purpose of
>>> a
>>> URL here.
>>>
>>> If I write a a cool essay, say, and I stick that up at
>>> nslater.org/my-cool-essay, then I can link to it from other places on the
>>> web using that address. I might also want to put my cool essay on Dropbox,
>>> or post it to Tumblr, or send it in an email. Now my cool essay has lots
>>> of
>>> URLs. Each one of them perfectly valid. I don't have to go and edit the
>>> original copy at nslater.org/my-cool-essay, because I am making copies of
>>> it. My cool essay is completely unaware of the URLs that are being used to
>>> point to it. And it doesn't care that many URLs point to it.
>>>
>>> Yes, URLs can be used as identifiers. But when you do this, you tie the
>>> thing you're naming to the place you're hosting it. Sometimes that is
>>> useful, other times it will cripple you. There is nothing about URLs that
>>> requires you to do this. I would hazard a guess that 99% of URLs are
>>> de-coupled from the things they point to. WebArch is much more robust when
>>> the identity of the object is de-coupled from the URL. Look at Atom, the
>>> ID
>>> element is supposed to be a URL, but they recommend a non-dereferencable
>>> format, precisely to decouple posts from the location you happen to be
>>> hosting them this month.
>>>
>>> Hey, if we're gonna use URLs, maybe we want to go down the same route?
>>>
>>> http://en.wikipedia.org/wiki/Tag_URI
>>>
>>>
>>> At this point, I'm not sure what they buy us over UUIDs.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>>
>>> N
>>>