incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ara.t.howard" <ara.t.how...@gmail.com>
Subject Re: uuid, auto-increment, et al.
Date Mon, 20 Oct 2008 21:54:43 GMT

On Oct 20, 2008, at 3:31 PM, Nick Johnson wrote:

>
> If you have 'user' docs and 'email' docs (which may simply contain  
> nothing
> but a reference to the user that owns the email), you can attempt to  
> insert
> both a new user doc and a new email doc in a single bulk write  
> transaction.
> The transaction will fail if either one already exists.
>
> This doesn't really work with my proposed sharding method, however,  
> since
> you can't guarantee both entities will hash to the same shard. You  
> could
> insert one doc then the other, and if the second insert fails, roll  
> back the
> first one, though.


yup, basically what i'm doing, the only issue is that the 412 from a  
bulk upload tells you not which operation failed, so i'm doing it  
peice-wise sorta like this

http://s3.amazonaws.com/drawohara.com.snippets/create_user_with_unique_fields_rb.html

notice the object isn't *really* a user until the last step, once the  
doc has been created and each of it's fields inserted in a way that  
ensures they are unique.  because it's peicewise i can let the user  
know which bit was non-unique.  because the unique docs track their  
parent a kill -9 can be recovered from.

it looks that, more and more, any real world situation is going to be  
*massively* simplified by having a single write master.  another,  
similar, approach, is to use a rdbms for generating these sorts of  
unique bits and possibly indices of documents, but to use to store the  
actual object graphs.

cheers.

a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama




Mime
View raw message