On Mon, Sep 22, 2008 at 9:11 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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).
I didn't see anywhere that Malcolm claimed a transaction will magically make concurrency issues go away all on its own, and I'm a bit put off by the fact that you're here: 1. Overloading the word "integrity" with multiple meanings and choosing which one you want to use at a given moment, and 2. Doing a lot of dancing from one issue to another (one moment you're talking about BEGIN/COMMIT causing overhead, the next you're arguing about transaction isolation). Can we figure out what this thread is about, and stick to it, please? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
