My understanding of why you wouldn't want to support using both kwargs at
the same time is that it would negate any performance gains from using the
DB's delete.
DB_CASCADE has the advantage of not making django run extra queries against
every model relation to determine which other tables nee
>
> There's also the added burden on explaining that we can only pass one of
> the two kwargs, and not use both at the same time. I think that favors
> overloading a single kwarg.
>
I'm not clear *why* you wouldn't be able to use both at the same time? In
fact, this seems like the primary be
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 th
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
Hi All,
I've taken interest to implimenting built in django support of ON DELETE
CASCADE. As a general concept, the ticket was accepted 3 years ago, and
there was some discussion around that time:
https://code.djangoproject.com/ticket/21961 . I've put together a small PR
with some but not all
