Last modified: 2014-11-07 13:07:41 UTC
Wikibase imposes some hard constraints on entities, by requiring some of their properties to be unique - for instance, only one item can have a link to a given site and title, and only one property can have a given name in a given language. We must ensure that these constraints are enforced in the same transaction that performs the primary data save. Not only have the constraints to be checked in that transaction, any updates of reference tables for the unique properties also have to be done in that transaction. This is currently not the case, it seems. Note: prepareSave() is called within that transaction, before the primary data is saved. doEditUpdates is called after the primary save, but outside the transaction. doDeleteUpdates is called after a page is deleted, but within the primary transaction. We may need an afterSave() method that is called after the primary save, but inside the transaction. Beware lock retention times: doing more things in the primary transaction increases the likelyhood of timeouts/deadlocks.
Is this the same as bug 42325?
MediaWiki doesn't give us enough control to assure full transactional integrity. Generally, MediaWiki chooses performance over db integrity, e.g. by sacrificing transactional scope for reduced lock retention times. As of now, we check global constraints inside the main transaction (via prepareSave), but update secondary tables only after the main transaction (via doEditUpdates and doDeleteUpdates). This follows the precedence set by MediaWiki core for updating secondary tables like pagelinks. It's more problematic for tables that are used to enforce global constraints, but I think we can live with it for now. Closing "wontfix" since I see no way to fully fix this without sacrificing scalability, and we are doing "pretty good" as it is.
