> It will also leave things vulnerable to having only some of your objects > updated, some of them deleted, some of them saved with no way to restore > to a known state. This proposed change is a bit more complicated than > the patches in #3460, since it's kind of a good thing to preserve > integrity of operations for things like saving, deleting and updating. > All of those involve more than one SQL operation in the general case.
I don't object to you wanting more work on #3460. You are probably right that it isn't perfect. However, Django also misuses transactions in other cases (exactly the ones you mention). A transaction does not guarantee consistency of multiple operations, at least not in the default READ COMMITTED transaction mode. Django is written assuming that the database transaction mode is SERIALIZED, which basically never true (someone would have to explicitly configure postgresql for this, and I'm guessing no one actually does aside from places like banks). READ COMMITTED mode means that each statement sees a consistent view of the database up to and included any transactions that were committed _while the current one was executing_. This means in a transaction like: BEGIN; SELECT username, password FROM auth_user WHERE id = 1; UPDATE auth_user SET username = 'foo', password = 'bar' WHERE id = 1; COMMIT; will do the wrong thing. Note that this is basically how Django does all its attribute updates. Let's assume that the Django code that generated this was user.password = 'bar' user.save() The problem here is that the SELECT statement will read all attributes, and before UPDATE is executed, another transaction may have changed the username column. Now the UPDATE actually reverts such a change because Django does not keep track of which attributes have changed. (Collin advocated very strongly for this patch in Portland, but it was also not included in 1.0). So here Django actually causes data loss due to the race condition, even though transactions are used. So please don't assume you're safe just because you are in a transaction. READ COMMITTED mode clearly does not work as Django database developers imagined. To me this is a far more serious bug than #3460, and I'm surprised it is not causing problems for others. It took us a long time to track this one down. jack. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
