> I don't want to get into the argument about ticket 3460 itself but I > just don't get this paragraph... What is special in web applications > that makes them not require transactions? And more, how transactions -- > a mechanism for preventing DB to end up in an inconsistent state -- can > get you into error cases?
We applications tend to be read heavy. Transactions are still needed; I never claimed they weren't. But most queries do not need to be part of a transaction to maintain consistency. For example: SELECT username FROM auth_user needs no BEGIN/COMMIT pair. Adding one will still work, but causes a fair amount of overhead on top of the normal query. The weird error case occurs because the developer has not explicitly stated they want a transaction, and yet they find they are in one. When an error occurs in a transaction, you must rollback and start a new one. When an error occurs outside a transaction, it is enough to retry. This is where the "helpful" DB-API abstraction starts to leak. It doesn't shield you from these two different error recovery scenarios, as Richard found out. 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 -~----------~----~----~----~------~----~------~--~---
