#33586: Cannot delete object (A) referenced by another object (B) if said object
(A) has a foreign key to a custom user.
-------------------------------+------------------------------------
Reporter: Jeremy Poulin | Owner: Bhuvnesh
Type: Bug | Status: assigned
Component: Migrations | Version: 4.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by Simon Charette):
> These lines were loading apps when the migration is applied backward.
Effectively, it's exactly what they were meant to do
[https://github.com/django/django/commit/5aa55038ca9ac44b440b56d1fc4e79c876e51393
for performance reasons] so unless we can demonstrate
As the comment references to this use to be done there for performance
reason. You can find more about the rationale by using `git blame` in
[https://github.com/django/django/blame/cfe3008123ed7c9e3f3a4d51d4a22f9d96634e33/django/db/migrations/executor.py#L203
the area surrounding the bits of codes you are proposing to alter].
It's a great sign if the test suite still passes but it's not enough to
merge this change. You should be able to demonstrate and explain why this
change is needed by writing a minimal test case from the issue reported by
Jeremy that can be integrated to the suite and demonstrates the origin of
the issue. From there we'd need numbers on the effect it has has on
performance to determine if that's the right place to make the changes.
This might seem daunting but solving issues in this area of the code base
is inherently complex as a lot of time went into making sure it performs
reasonably well. The good news is that since
5aa55038ca9ac44b440b56d1fc4e79c876e51393 was merged a lot of efforts went
into making sure non of the core operations that Django provides relies on
`state.apps` in their `state_forwards` which makes the layer in charge of
''emulating'' `state_backwards` way faster so there are reasons to believe
that this eager rendering of models might not be necessary anymore until
the plan is fully applied.
It is still required for most `database_backwards` operations though (see
#29898) as well as `post_migrate` signals emission so I get a feeling that
avoiding the eager rendering as your patch suggests doing will do more
harm than good.
My gut tells me that we're failing do some cache invalidation during one
of the `state_forwards` operation and that this where the issue should be
solved.
--
Ticket URL: <https://code.djangoproject.com/ticket/33586#comment:15>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701835760679c-668443ac-aa94-4792-b4ca-7c501d5263c2-000000%40eu-central-1.amazonses.com.
