On Saturday 02 March 2013, Aymeric Augustin wrote: > On 2 mars 2013, at 16:18, Shai Berger <s...@platonix.com> wrote: > > -1. Make it easier (and cross-backend) to set db-level-autocommit on. Put > > the setting for it in the default template for new projects. Don't > > change existing code from "fragile" to "subtly broken". > > This isn't simply about changing some default. It's about re-implementing > all the transaction machinery. > > With the scope I described, I estimate that I can complete the project in > 120 to 200 hours. If I have to keep bug-parity with the current behavior, > I estimate that I'm not capable of delivering it. > > In other words, you're requesting that I fork Django rather than contribute > this to the main tree.
I may have phrased my objection too strongly -- all in all, I laud your continuing effort to improve Django and its database layer, including this change. However, I must stand my ground. The Django documentation on transactions, at the moment says this on Django's default behavior[0]: > Django’s default behavior is to run with an open transaction which it > commits automatically when any built-in, data-altering model function is > called. For example, if you call model.save() or model.delete(), the > change will be committed immediately. Now, you want to call this behavior (the part where there's one open transaction, rather than one-per-db-operation) a bug. I find that a little odd, but I can live with it. What I have a harder time living with is my other point, which has not been refuted: The proposed change turns code that is currently correct -- liable to break if changed, but still correct as it stands -- into code with "phantom bugs" that show up only in production, under specific timings of concurrent requests (because reads and writes which used to be in the same transaction are now on separate transactions). It is my opinion that such changes may only be made when changing major versions (i.e. Django 2.0), if at all. If anyone can offer a way to detect the situation and warn users of the change, that would make things perfectly fine. Changing the default transaction behavior along the lines you suggested would be a great improvement. I have a strong suspicion, though, that if the new behavior is implemented as default (and with no recourse to the old behavior, to boot), then that simply cannot be done. I think that as suggested, the change would break the project's committments to its users in a way that is much more important than the performance gains, avoided idle-in-transaction errors, and effort considerations, all put together. That is my objection. Thanks for your attention, Shai. [0] https://docs.djangoproject.com/en/dev/topics/db/transactions/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
