Hi Peter, Thanks for that; I've just marked the ticket as a release blocker, so at the very worst, this should be corrected for the 1.5 release.
Yours, Russ Magee %-) On Tue, Aug 28, 2012 at 11:56 PM, peter <[email protected]> wrote: > The wrong rows being deleted is a possibility. Here's an example: > > class Through(models.Model): > two = models.ForeignKey('Model2', to_field='spot') > one = models.ForeignKey('Model1') > > class Model1(models.Model): > name = models.CharField(max_length=100) > > class Model2(models.Model): > spot = models.IntegerField(unique=True) > ones = models.ManyToManyField(Model1, through=Through) > > # Create objects and relations > m = Model1(name='test') > m2 = Model2(spot=2, pk=1) > m3 = Model2(spot=1, pk=2) > m.save() > m2.save() > m3.save() > Through(two=m2, one=m).save() > Through(two=m3, one=m).save() > > # Both have ones > m2.ones.all() > m3.ones.all() > > m2.ones.clear() > > # Still has ones, didn't get deleted when it should have > m2.ones.all() > > # This got deleted instead > m3.ones.all() > > It's not exactly a real world example though i think it demonstrates that > data loss is a possibility. > > Monday, August 27, 2012 5:33:03 PM UTC-7, Russell Keith-Magee wrote: >> >> On Tue, Aug 28, 2012 at 3:11 AM, peter <[email protected]> wrote: >> > I opened this ticket (https://code.djangoproject.com/ticket/18823) on >> > the >> > Trac but thought i'd bring it up here to increase the likelihood of it >> > getting noticed. In short things don't quite work right when you have a >> > m2m >> > field that uses a through model that uses a to_field for it's foreign >> > key. >> > If someone wouldn't mind reviewing the patch and giving me some >> > feedback, >> > I'd like to help get this issue fixed. >> > >> > Assuming a fix in some form is accepted, I was also wondering if this >> > bug >> > fix would be considered important enough to backport to bugfix branches? >> > Or >> > will we need to wait for the next major release to get the fix in an >> > official release. >> >> Generally speaking, we don't backport bug fixes unless they relate to: >> >> * Security issues >> >> * Major problems with newly added features >> >> * Problems with the potential to cause catastrophic data los -- i.e., >> accidentally deleting/dropping data, or deleting/dropping the wrong >> data. >> >> A rule of thumb: If we'd discovered this feature the day before we cut >> a major release, would we have held back the release? >> >> In this case, it's not a security issue, and the code has had this >> problem for several years; we certainly aim for being bug free, but >> we've evidently survived with this bug for some time without any >> serious problems. However, you *might* be able to make the case that >> catastrophic data loss is possible. From an initial analysis, it seems >> like it might be possible to accidentally delete the wrong through >> model. If you can provide a clear example of a case where this would >> happen, then yes, a backport is likely. >> >> Yours, >> Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/hzKJaotTKkQJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
