#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: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Changes (by Simon Charette):
* needs_better_patch: 0 => 1
* has_patch: 0 => 1
* needs_tests: 0 => 1
Comment:
> you were right, the problem was inside `RunPython.state_forwards` as it
is not mutating any state
Sorry for not being clear but I think you've misinterpreted me here, I
never stated the issue was in `RunPython.state_forwards` and it's expected
that it doesn't mutate state as it's an operation that is meant to be used
for [https://docs.djangoproject.com/en/4.1/topics/migrations/#data-
migrations data migrations]. The symptoms of the issue, corruption of
project state, can be observed in `RunPython.state_forwards (and it's
resulting call in the function provided to `RunPython` initialization as
reported in this ticket) but it's almost certainly not its cause. In other
words, `RunPython.state_forwards` cannot be the origin of the state
corruption because it doesn't mutate it.
> one thing we can do is clear apps cache inside database_backwards for
RunPython Operation. This should also not affect the performance much.
Do you have any numbers to support your performance claim? This is
important as you are forcing the eviction of a cache layer dedicate to
making performance better.
> Ps: Passing all tests.
That's expected as explained in comment:15 but it cannot be intepreted as
the proper solution to the problem.
> Do i need to write regression test also for this?
Absolutely! You need to demonstrate ''what'' caused the app registry to
get corrupted in the first place and not only hide it's side effect;
that's the crux of the issue here.
Even by putting the performance regression aspect aside I don't think the
proposed solution is correct. Rendered models are also provided to
`post_migrate` signal receivers which means that it could be corrupted
there as well and the solution here **is not** to clear the cache at this
location as well.
--
Ticket URL: <https://code.djangoproject.com/ticket/33586#comment:19>
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701839f1f6e6a-e2cc08a8-e71e-4fbc-adab-2f230e59289c-000000%40eu-central-1.amazonses.com.
