Thanks for the feedback Anssi. The original ticket talked about making DB_CASCADE work where it can, and adding warnings to most other places. I've updated the PR with checks warnings for the following cases (including tests for said checks cases):
- GenericForeignKey + DB_CASCADE (#4 in the Original Post) - concrete model inheritance + DB_CASCADE (e.g. the example Anssi gave above, and #5 in the OP) - model A DB_CASCADE --> model B CASCADE (wont get triggered) --> model C (#3 in the OP) If anyone wants to take a look: https://github.com/django/django/pull/8661 Nick On Thursday, July 27, 2017 at 1:19:19 AM UTC-7, Anssi Kääriäinen wrote: > > On Tuesday, July 25, 2017 at 5:34:33 AM UTC+3, Nick Stefan wrote: >> >> 5. Q: implicit foreign keys between child to parent in model inheritance? >> A: We could forbid models.DB_CASCADE on these types of relations? >> > > There's actually a variation of this that seems a bit hairy to solve > properly. For models: > > class Category: > pass > > class Child: > pass > > class Parent(Child): > category = models.ForeignKey(Category, on_delete=DB_CASCADE) > > Then, when you delete a category instance, the associated parent instance > will get deleted, but the child instance won't (as there's no foreign key > from child to parent, we can't make this work in the DB without using > triggers). > > Now, the problem here is that this actually leaves the database in an > inconsistent state. I guess the solution might be to document this, add a > warning to checks done on startup, and let users deal with the > inconsistency if they so decide. > > We could solve these problems by including an O2O from both parent to > child and from child to parent, and making them both DB_CASCADE. That's not > a good idea for other reasons (complexity of saving a new instance to the > database for one). If we want to make these cases work seamlessly directly > in the database, it's likely better to add in triggers. It wouldn't be > horribly complex code to write. The hardest part would be making sure the > triggers are kept in sync when doing migrations. > > For the other parts your proposal does make a lot of sense to me. Don't > fall in the trap of complexities in parent -> child cascade. Just add > warnings and that's it. > > - Anssi > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0119909c-2fa6-44c6-b0c5-5991c5c368ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
