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.
As of the MySQL issue, using a higher isolation level might fix the issue 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. If you still go this path, it would be a good idea to have the isolation level change not set globally (on settings) but have it as an argument to the transaction.atomic() function to be able to change it per transaction. Would it work if rather than performing a DELETE, SELECT, INSERT combo, you perform a DELETE and INSERT IGNORE ? I believe it is supported by MySQL and PostgreSQL has a similar functionallity starting on 9.5 but can be emulated through locks or nested queries. What if there could be a way to store the last modified date of an object (check it's history maybe?), save that date locally on the admin form, and when performing the actual save compare those two and prompt an error if they do not match, that would prevent most concurrent modification issues (although make it a bit more anoying for edits that usually do not have any issue), although you might still be prone to a small race condition on the modification date, unless yo uperform a select for update on it first. El lunes, 14 de marzo de 2016, 12:15:31 (UTC-3), Tim Graham escribió: > > Could some MySQL users take a look at ticket #26347 [0] and recommend how > to proceed? I think it's probably not a new issue but I'm a bit surprised > it hasn't come up before if so. > > [0] https://code.djangoproject.com/ticket/26347 > -- 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/01264edf-73db-4533-8210-bc35448029a8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.