couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Couchdb Wiki] Update of "Transaction model use cases" by damien
Date Sat, 11 Apr 2009 01:09:52 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by damien:

  Alternative use case: user is being deleted. References need to be removed from multiple
groups. Database dies in the middle because of the power outage?
+ '''''Put the user into an "about to delete" state. Then remove the user from all groups,
then completely delete the user. To deal with failures in the process, periodically search
for users in the "about to delete" state and remove them all groups, then delete the user.
This is how Lotus Notes handles it.'''''
  I guess what I am trying to say here - given an isolated scenario with just 2 entities,
it's pretty much always possible to define the model in such a way, that a 'problematic' operation
would be handled correctly transaction-wise, that is, it boils down to a single doc update.
But once the model starts getting more complex, with multiple relations, sooner or later you
end up with multiple documents being updated as a single logical action. This might also happen
because of the model restrictions as the application evolves, and the entities and their relationships
that were supposed to handle every use case suddenly don't do that anymore. This document
'normalization', for the lack of better name,  very soon starts imposing serious restrictions
on the design of the document entities and the associated application logic, that would be
easily avoided by the presence of a multiple-doc transaction model. Also, don't get me wrong
- I haven't been that impressed by a persistence 
 solution for quite a long time, and I've tried quite a few - and couchdb did just that :)

View raw message