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
>
> 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
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
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
