#22874 closed Bug (fixed)
Swappable dependency breaks if swappable model not in first migration of its app
Reported by: | Stephen Burrows | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Release blocker | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Right now, it's impossible to declare a dependency to/from AUTH_USER_MODEL.
Here's the error I'm getting:
ValueError: Lookup failed for model referenced by field feedback.FeedbackItem.user: brambling.Person
This is bad on two fronts:
- From the "brambling" side - the side declaring/using an AUTH_USER_MODEL - I can't use the "feedback" module because it doesn't declare a dependency on my model - and django doesn't currently support reverse dependencies (unless they're undocumented.)
- From the "feedback" side - the side with migrations and a swappable FK - the app can't be used by anyone who actually has a swappable model, because there's no way to declare a correct migration dependency.
I feel like the correct fix here would be to have a 'swappable dependency'.
This is on stable/1.7.x
Change History (8)
comment:1 by , 10 years ago
Summary: | Need a way to declare a dependency for AUTH_USER_MODEL. → Swappable dependency not working |
---|
comment:2 by , 10 years ago
Summary: | Swappable dependency not working → Swappable dependency breaks if swappable model not in first migration of its app |
---|
It seems like this wasn't working because swappable dependency automatically goes to the first migration in the swapped model's app - and if the swappable model isn't migrated into existence in the first migration, the swappable model dependency breaks.
I don't think this would be a serious problem in the future - brambling has some slightly older 1.7 migrations, from back when it would generate a million of them. I believe it's now consolidated down to one initial migration, so most people probably won't run into this.
Workaround was to add a dependency to the last migration in the swappable model's app. Would that work for the swappable model dependency behavior? (I could also imagine situations where a swappable model is switched out for a different one over the course of the app.)
comment:3 by , 10 years ago
Version: | 1.7-beta-2 → master |
---|
comment:4 by , 10 years ago
Reverse dependencies are possible, just not documented - use run_before
in the same way you use the dependencies
attribute.
comment:5 by , 10 years ago
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
This is a valid bug, not sure if it's considered release blocker - will bump up and let andrew decide.
comment:6 by , 10 years ago
One of the caveats we had to do to be able to support swappable models was that they MUST be in the first migration of their respective app (as you've seen, otherwise dependency problems occur). There's literally no way to fix this, as it's logically impossible to construct a dependency graph otherwise with our model.
I'll add documentation highlighting this next to the existing warning about dependencies from unmigrated apps.
comment:7 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
... wait, swappable dependencies are totally a thing. Okay. So why isn't this working?