On 2 mars 2013, at 21:46, Shai Berger <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
