Thanks for your response. In general, seems like you always need some kind of
external coordination if you are doing inverted indexes. How do others tackle
this issue?
Now would using secondary indexes be a good idea in this case considering
cardinality of the keys will be pretty high?
cheers,
Drew
On Apr 13, 2011, at 4:51 PM, Eric Evans wrote:
> On Wed, 2011-04-13 at 15:07 -0700, Drew Kutcharian wrote:
>> username = 'jericevans'
>> password = '**********'
>> useruuid = str(uuid())
>> columns = {'id': useruuid, 'username': username, 'password': password}
>> USER.insert(useruuid, columns)
>> USERNAME.insert(username, {'id': useruuid})
>>
>> How can I guarantee that USERNAME.insert(username, {'id': useruuid})
>> won't overwrite someone else's account. What I mean is how can I
>> guarantee that a user's username doesn't already exist in Cassandra? I
>> know I can check first, but in a highly concurrent environment,
>> there's a possibility that between USER.insert(useruuid, columns) and
>> USERNAME.insert(username, {'id': useruuid}) someone else does the same
>> USERNAME.insert(username, {'id': useruuid}) and hijack the user's
>> account.
>
> Yes, this is a flaw. You'd need some sort of external coordination to
> be sure you could prevent this.
>
> There are probably many such flaws, Twissandra wasn't meant to be a Real
> app, it's an aid in teaching the query and data models, and a lot was
> glossed over to keep it concise.
>
>> Seems like that USERNAME is something that the author has added since
>> it's missing in original Twissandra source code.
>
> Right, since that article was written, the Username column family was
> removed, and the User column family is now keyed on username (which
> solves the problem of concurrent updates, by making it "last write
> wins").
>
> --
> Eric Evans
> eev...@rackspace.com
>
