On 21 Mar 2016, at 15:02, Hugo Chargois <hcharg...@medici.tv> wrote: > > But here, we have "two non-conflicting updates (no-ops, even) causes data to > be lost". I bet no one would call this safe.
Yes, this one was clearly a bug (and, if I understand correctly, it was resolved by a not-directly-related change, originally considered a performance optimization). What I meant, but failed to convey clearly, is: can we derive general and useful rules from this bug, or are we stuck with dealing with such problems on a case by case basis? In theory, we could: 1. make a list of “atomic” ORM operations (create, update, delete, etc.) — things you write in one line and thus expect to complete consistently 2. figure out which operations incur multiple queries — concrete inheritance and many-to-many relationships come to mind 3. investigate what unexpected results could occur in the presence of concurrent queries — I have no idea how to do that exhaustively Furthermore, I suspect the answer to 3. will be “anything could happen” at lower isolation levels and “that looks be safe” at higher isolation levels. I also suspect there’s little we could do to improve the situation at lower isolation levels, except if we have other instances of unoptimized M2M code. (Optimizing for performance means making fewer queries means improving chances of transactional correctness.) In the end, “figure out where the ORM could do fewer queries” sounds like a easier plan than “figure out all possible sequences of queries and whether they’re safe”. -- Aymeric. -- 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/44DC4C9E-74FC-43A0-8394-F0035DED3970%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
