incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: unique constraint in couchdb
Date Thu, 20 Oct 2011 13:56:29 GMT
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
<patrick.petermair@openforce.com> 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: "foobar@foo.at", timestamp: "2011-10-20T10:10" }
> { user: "foobar@foo.at", timestamp: "2011-10-20T11:50" }
> { user: "otheruser@foo.at", 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
>

Mime
View raw message