On 13/01/2009, at 11:42 AM, James Marca wrote:
You are restricting the use of _id for this "feature" due to your
design decision of using just integer ids. But I don't think you can
also complain that there is no way to guarantee the uniqueness of an
arbitrary (set of) field(s). There is, you're just not using it.
Again, I haven't been using couchdb for more than two months, but I'd
guess the developers are not going to see a need to allow for
*another* guaranteed unique field.
Particularly given that the uniqueness of the id field is to do with
document identity, rather than uniqueness per-se.
A fundamental issue you have to remember is that Couch is designed to
act in a disconnected p2p fashion. Different peers can create and edit
documents, and when they replicate you get conflicts that have to be
handled without the benefit of any global conflict resolution. This is
why considerations of uniqueness are a dead-end. You have to think in
terms of document identity, and the ontological mapping of that
identity. If identity in your domain is determined by the name you
give something, then that should be the id, and if you use writable
replicas then you need to handle replication conflicts. So uniqueness
in the sense that you are looking for is just not part of Couch's big
picture. As soon as the concept of 'lock' appears in your thinking,
you know you're on the wrong track.
As others have said, if you want a global state you need to look for
something outside of Couch, and that has it's own problems because
global state in a distributed manner is dependent on connectivity.
CouchDB is so far from a relation database that even including the
word 'database' (DB), with all of it's presumptive extensions, is
unfortunate IMO.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Isn't it enough to see that a garden is beautiful without having to
believe that there are fairies at the bottom of it too?
-- Douglas Adams
