Hi Patrick, Try to look on problem in another way. Each document describes some event, some complete object part of those couldn't be changed from outside. In this way, you'll have two types of documents: first is the event that describes by user and timestamp and second one is the object that should be created right after of this event - what exactly have done by this event. So event document would have unique id to prevent duplicates of same events while object id should be unique for objects family. And I see problem no more(;
P.S. small profit of this solution: you would have full history of events that have affected on single object document. -- ,,,^..^,,, On Thu, Oct 20, 2011 at 3:57 PM, Patrick Petermair <[email protected]> wrote: > hey! > > ist there a way to ensure some kind of unique constraint in couchdb other > than the document id? > > for example: > we have multiple documents that each represent a timestamp of a user. > > { user: "[email protected]", timestamp: "2011-10-20T10:10" } > { user: "[email protected]", timestamp: "2011-10-20T11:50" } > { user: "[email protected]", timestamp: "2011-08-20T08:11" } > ... > ... > > we now want to ensure, that a user can't have 2 documents with the same > timestamp .. basically creating a key for user + timestamp. > > the solution so far is to create a view with a key of [user, timestamp] and > check after every document creation/update if there are more than 1 > documents for a given user + timestamp tuple. > this obviously has the performance penalty of having to do a seperate db > call. it also leaves the db in an inconsistent state until it is resolved. > > the other solution is to use the user + timestamp as document id. but this > would require to update the document id whenever the timestamp is edited. > > are there any other solutions? is there something on the roadmap for couchdb > that would solve our unique key problem? or is couchdb simply the wrong tool > for the job? > > thanks! > patrick >
