Last modified: 2012-12-13 11:17:32 UTC
The item edit functionality has to implement detection of edit conflicts. Even with atomic edits and an Ajax based UI, edit conflicts can still happen and lead to inadvertedly overriding someone elses work: 1) A loads page X, with property foo=2 and bar=bla 2) B loads page X, with property foo=2 and bar=bla 3) A sets Foo from 2 to 3 and saves 4) B sets Foo from 2 to 4 and saves 5) B has unknowingly overwritten A's change. Conflict resolution will be trivial with atomic edits, though: if A and B change different properties, they do not actually generate a conflict.
Keep revid for background page in user interface, but maintain also a list of last observed revid for other fields. On edit supply the last observed revid to the API which then supplies the revid to doEditContent. If the edit succeed the new revid is reported back to the requester. The requester then knows that the old revid can be replaced by the new revid, so it updates other revids including the one used for the background. If a new revid is not reported back there is an edit conflict. All non-changed fields can then be updated anew but the user interface must somehow show the conflict for the specific field if that is the one he is editing. Somehow-ish...
I think that's pretty much how EditPage does it. I suggest we try to make the behavior consistent with what happens for wikitext. Maybe ApiEditPage can help us to find out how it's done best. If ApiEditPage does in fact do conflict detection.
Send the old value and check if it is still the old value. If it is not, report a conflict. Think about set based values again, if this actually works.
For now: simply detect such a collision and report it, telling the user to reload. This contains an API part and a UI part. Before closing this item set up a new one for making it nicer (e.g. maybe let the user change to override the change, abandon its change, reload this field?, reload all?, etc.)
It seems like collision detection works in some cases, but it then simply fails on save. I saw this behavior when doing upload by importInterlang.php, but could not duplicate the behavior when being logged in with two user accounts on the same repo.
Changed title to reflect this is not item specific. Most code will be on entity level, with maybe some specific handling per entity type (ie item, property, query).
Disregard my comment #3. Send instead the base revision, take the value from there, compare it to the current value, and update if equal to the new value.
Final version for now is "detect such a collision and report it, telling the user to reload." That means no patching as of now.
Verified in Wikidata demo time for sprint 14
