Why does transaction management only commit on is_dirty? I realize that the answer to this question is, "Why commit if there are no changes to the database?", but it's a bit more complicated than that.
Let's assume a reasonably common case: 1. psycopg2 + PostgreSQL. 2. Transaction middleware enabled, or @commit_on_success decorator. 3. Read-only view function. In this case, psycopg2 will begin a transaction on the first database read, but no COMMIT will ever be sent to the database. Until the connection actually closes, this means that the connection will be in <idle in transaction> state on the PostgreSQL server, an expensive state to be in. (A pile-up of <idle in transaction> connections is a pretty common occurrence in Django applications, in my experience.) It seems that this problem is trivially fixed by always committing in the places that a commit depends on is_dirty(). The commit should be near-free on any back-end, since there are no changes, and it eliminates the IIT issue on PostgreSQL (and perhaps other problems on MySQL that I'm not as familiar with). What am I missing? -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
