On Sun, 2008-09-21 at 11:32 -0700, Richard Davies wrote: [...]
> I suspect that this will significantly simplify the Django codebase > vs. > trying to simulate both auto-commit and transaction behaviors on top > of a transactional connection - it would certainly remove most of the > mechanisms in django/db/transaction.py which track state, dirty, etc. 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. As I mentioned previously, we're always going to need some transactional management for stuff like that, so this is going to go a lot further more easily when we have a patch that allows the behaviour to be controlled. Then we can worry about what the default setting might be. At the moment #3460 provides a good way to end up with inconsistent data due to interactions with other transactions and an inability to roll back to the start. The fact that none of the many patches on that ticket even touch save/update/delete handling has to be an error. Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
