Hi, I just commented on the ticket, but wanted to clarify a few things here:
On Tuesday 15 March 2016 00:48:02 Cristiano Coelho wrote: > The django-admin interface is quite bad at handling concurrent > modifications, this is one problem that might not happen on other backends > and is quite critical, but other issues (that ain't critical like data loss > but might cause unexpected errors) like two people viewing a model with > some inline relations, one of them deletes one of the inline rows, the > other one performs a save, it will try to re-save the one that's actually > deleted and you end up with a "please correct the errors below" but you > actually see no errors (because the row you tried to save no longer exists > and is no longer loaded). Similar errors happen with other kind of > concurrent modifications. Right. > As of the MySQL issue, using a higher isolation level might fix the issue For the record, the suggestion made was to use a *lower* isolation level, to prevent the failure of transactions; I disagree with that recommendation, as it "prevents" the failure by enabling the kinds of data corruption you described above. > but I would strongly recommend not changing it as this is mainly an issue > of how django performs the many-to-many save and not MySQL's fault at all. ... and there I completely disagree. Django handles the updates in a transaction; first it deletes records, then (if they don't exist) writes them. The MySql docs explain that records are "snapshotted" at the beginning of the transaction, and so may actually be stale later on in it -- but that does not hold when the changes to the records are done *in* the transaction. I asked the ticket's OP to describe a scenario where this is anything but a severe MySql bug, and I ask the same of you. Shai.
