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
