I can't tell if it is a bug on MySQL or not, but I did understand the same as you (the first example with Session A and Session B makes it more clear) so I can't quite understand how did the poster get that issue. I would like a similar example as the one in the docs, but with a delete in the middle, it is a bit unclear what happens, could a delete in the middle create a new "snapshot" for your next select?
So assuming the issue is real and not a bug in MySQL: - Would a DELETE + INSERT IGNORE fix the issue, while also improving many-to-many updates to backends that support INSERT IGNORE? (one less select) - Would a different isolation level help? What about SERIALIZABLE? In order to do this, the only good way to do this is to have the option to change serialization level on each transaction, improving the transaction.atomic() method so we do not affect other db operations changing the isolation level globally. - Force a lock to the many-to-many updates (using select for update maybe?) ? - Use the object history to perform date matching and detect concurrent modifications of the same object before we do them and raise an error? El lunes, 14 de marzo de 2016, 20:12:29 (UTC-3), Shai Berger escribió: > > 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. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1df2641a-cdd9-49b9-b3fa-56dbe707fd8d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
