https://bugzilla.wikimedia.org/show_bug.cgi?id=36431
--- Comment #4 from Daniel Kinzler <[email protected]> 2012-05-07 12:50:23 UTC --- I agree that we need a Content::isValid() method (or maybe better: getErrors(), returning a Status object or false). Checking this before save is something that would need to be done in core, I guess. (By the way - being able to cache the result of this check would be a reason to have non-mutable Content objects. Caching would be useful since the check may be called multiple times during a save, on different levels of processing) I think doing this kind of check before saving is the first thing we need to do, no matter how we try to enforce database consistency. By itself, it introduces a race condition of course. But one that would rarely be hit. While we should try to avoid inconsistent database states, it would be fine to just show a database error message or some such in case we hit a conflict. As to keeping the database consistent, here's the key points: * checking validity, saving the primary blob and storing secondary data must all happen in the same transaction. * if everything should be consistent, there's no distinction (in this context) between primary and secondary data. Indeed, it would be handy to perform the "primary" update the same way the secondary updates are performed: using a list of objects representing updates jobs. * we should consider the case of having secondary data on several different database systems. * full ACID conformance always bares the risk of operations blocking for a long time (because of retires in case of communication failure in the commit phase). Eventually, I think it should work this way (in core): * The initial validity check, writing the primary blob and updating the secondary data stores should all be modeled as update objects. * When a page is to be saved, a list of update object is constructed. Each update object can open/commit and abort a transaction, and perform the actual update. * The update is then performed in 3 stages: open all transactions, do all updates, then commit all transactions. It would be very hard to make the commit phase truly atomic. I believe we will have to live with the risk of inconsistencies introduces by connections failing the the middle of a transaction. Anyway, for now, I think it's sufficient to implement a pre-save check without any transactional logic. We should keep the transaction stuff for later. Maybe in a separate ticket. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
