On Tuesday 05 March 2013, Aymeric Augustin wrote: > On 5 mars 2013, at 01:50, Shai Berger <s...@platonix.com> wrote: > > I want to point out how ironic this whole issue turns out. > > That's a storm in a teapot. Let's keep some perspective:
I really had no intentions of disrupting the weather; however, > - People using MyISAM aren't affected. That's been recommended against for ages; InnoDB has been the default since MySQL 5.5, 12/2010. Django 1.3 was released three months later, and I think you can safely assume the usage of MyISAM in projects developed since 1.3 is negligible. > - People using the transaction middleware aren't affected. That's your group 3... > - People using commit_on_success aren't affected. ... and that's your group 4. > > In addition to the above, to end up with data corruption, you must: > > - be aware that MySQL runs on "repeatable read" by default, > - have checked that Django doesn't set another isolation level — this isn't > documented, > - be aware of Django's default transactional behavior — > virtually no one understands the first paragraph of the transaction docs, > - have chosen to rely on this behavior to implicitly guarantee some > integrity between a read and a subsequent write, No you don't; that's a key point that, for some reason, I haven't been able to push through. Code correctness is not dependent upon the state of mind of the author. At least the "delete duplicates" example I've pointed to shows, that it's quite easy to write code that is correct now, under the defaults, with MySql and will break with the change. It is easy to do so "unwittingly", with no real awareness of the details involved (arguably, making it easy to write correct code "unwittingly" is one of the goals of frameworks like Django in the first place). That is exactly the situation that I think is likely for your groups 1&2. I don't think the fact that their code is correct "by chance" gives us a license to break it. > - upgrade to Django 1.6 without taking into account the release notes or > without understanding their consequences for you, which is well within the norm for these users, > - be running a medium- or high-traffic website where race conditions are > likely, No, that's what you need to end up with large-scale data corruption. I'd phrase that point in reverse: To be safe, you need to run a very-low traffic website, where concurrency virtually never happens. > - have code that fails silently rather than raise an error on integrity > violations. > The problems caused do not necessarily create integrity violations. In the deletion example, they just make data go poof. > That's technically possible, but sufficiently unlikely to be acceptable as > a _documented_ backwards incompatibility. I agree that this conclusion follows from your premises. It's those premises that I disagree with. Shai. -- 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.
