On 2 mars 2013, at 21:46, Shai Berger <s...@platonix.com> wrote: > 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.
Yes, my proposal is a backwards-incompatible change with regard to this sentence. However, I believe that only a small fraction of the users of Django fully grok the implications of this sentence, and a fraction of this fraction relies on it to ensure some level of integrity. > 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). I'm aware of this scenario and I'm willing to document it in the release notes. > It is my opinion that such changes may only > be made when changing major versions (i.e. Django 2.0), if at all. The current consensus — at least within the core team — is that there will never be a "break everything" Django 2.0. I believe that the level of backwards-incompatibility described above is within acceptable bounds for Django 1.6. I also believe that it beats the alternative — namely, live with the current behavior forever. > 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. Yes, I agree with this way to frame the discussion. We reach different conclusions because I don't consider backwards compatibility an absolute that trumps every other consideration. It's a continuum. Backwards compatibility must find a balance with progress. The same goes for security: while extremely important, it still has to find a balance with usability — otherwise you'd never dare open port 80. -- Aymeric. -- 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.
