On Mon, Dec 12, 2011 at 1:09 AM, Jason Smith <[email protected]> wrote: > On Mon, Dec 12, 2011 at 5:16 AM, Paul Davis <[email protected]> > wrote: >>> A couch URL is its unique identifier. A database URL is its unique >>> identifier. This sounds like a too-clever-by-half optimization. IMHO. >>> >>> -- >>> Iris Couch >> >> To this I ask simply: What's the URL of my phone? Tying a URL to a >> database is like identifying a person by their address. A UUID per >> created database is much more fine grained, but has operations issues >> with file handling and what not. > > Hi, Paul. A database is not a person. It is a resource, with a > universal location. > > Databases can be replicated, or copied, or restored from backup. (Same > for .ini files.) > > One .couch file can be served from different URLs; and one URL might > serve different .couch files over time. The current replicator > understands this and if anything seems fishy, it double-checks. (For > example, the instance_start_time helps to detect wholesale replacement > of .couch files.) > > The web assumes that mostly, but not always, a stable URL represents a > stable resource. So does the replicator. Getting away from that seems > difficult. > > -- > Iris Couch
I think you've contradicted yourself. If a URL is the universal name for a database, then how are we able to server different databases from the same URL? Tying a database to a URL is merely an artificial limitation because we haven't thought of anything better. If we *did* think of a way to uniquely identify databases that didn't break due to ops requirements then that would be a much better fit to the CouchDB model. It is difficult but that's because we haven't yet thought of a good way to deal with what happens OOB when ops teams change server configurations.
