> > It is also highly inefficient for Web applications (since > > they most often do nothing transactional) and gets you into trouble in > > error cases. > > 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?
On the first question, I'd suspect that many pages of many (simple) web applications just have a one-to-one mapping between the web page and a single line of SQL on a normalized database - e.g. a page listing all events (single SELECT), a page listing all people at an event (single SELECT), a form to add an event (single INSERT), etc. Wrapping these in transactions is pure overhead. On the second question, one example is my initial bug report starting this thread (admittedly PostgreSQL specific). Object 'c' is not saved when you would have expected it to be (and it is on other database backends). The problem isn't that transactions are bad in themselves, but that the code runs in a imperfect simulation of an autocommit environment on top of an implicit transaction (which the user would not be expecting). Cheers, Richard. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
