> I believe this boils down to the same issue as ticket [3460] - both > the psycopg1 and psycopg2 backends are using the wrong isolation > level, as a result of which the Django SQL is wrapped by psycopg > inside an implicit transaction. I have tried using the [3460] patch, > which gives me the Postgresql behaviour that I expected.
Yes, This is exactly what [3460] solves, aside from the inefficiency of implicit transactions. Collin and I tried very hard to convince Jacob and others that this should be included in 1.0, but they disagreed and many of us must still maintain private forks of Django to get around this. I'll note that this isn't just a problem with Django, but with any naive use of Python's DB-API. For ease of use, DB-API wraps everything in a transaction. The end result is an API that works well for common use cases and is easy for developers to understand. It is also highly inefficient for Web applications (since they most often do nothing transactional) and gets you into trouble in error cases. > Whilst it's true that this would give auto-commit behaviour, there's a > valid alternate side to this that doesn't seem to be addressed: whether > that's actually a good idea or not. > > One reason not to do this is that it simply isn't standard behaviour for > Python database adaptors (they must be in non-autocommit mode > initially). So there's a principle of least-surprise thing going on. The principle of least surprise is for the database to act like a database. That means not wrapping things in implicit transactions which will surprise you on errors when the abstraction is no longer transparent. I find it less surprising if my database time is spent on inefficiently crafted queries instead of on overhead that I cannot control except through patching Django internals. Yes, DB-API has this default. We can argue all day about whether it is the right default. I believe that it exists because mysql does not have transactions (or at least did not back then) and the person who designed this API designed it for that case. Transactions were an afterthought; they cannot be controlled explicitly by the API as written. Even psycopg2's autocommit is specific to that implementation. For Django, not using the default behavior is a clear win. It doesn't create weird errors where hte implicit transactions are exposed. It is enormously more efficient when doing large amounts of queries that aren't transactional. It makes the explicit transaction control actually do what you intend (eg, autocommit decorator actually autocommits). > As I mentioned to Collin at the code sprint in Portland, I think it'd be > a good idea to make sure we expose the ability to turn on auto-commit, > but I don't really like making it the default. In any case, providing > the ability that's can be controlled via, for example, a setting is > certainly the first step here. That's pretty independent of the whatever > the default might end up being. That's really the improvement needed to > #3460 at the moment -- separating adding functionality from changing the > default. I do not understand your reasoning here. You seem to be saying "the DB-API guys were way smarter than all of us, and they must have had a good reason for doing it this way". This means Django does not do what it is capable of doing (ie, broken autocommit decorator) and remains inefficient in common cases. To my knowledge Perl and Java's database APIs do nothing like this. I suspect (but haven't verified) that Ruby is similar. Python is alone here in this implicit transaction garbage. Why have transactions _at all_ if they are always provided for you? I don't understand that part either. If you think users expect all these implicit transactions, it seems superfluous to have any explicit transaction handling in Django at all. Is it realy the user's expectation to have and use nested transactions? I think if you actually exposed the transactional overhead and the connection overhead in the django.db.queries array, you'd find that more of your users would be demanding fixes here. The fact that you hide this means people aren't even aware of the problems. 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 -~----------~----~----~----~------~----~------~--~---
