Opened 4 months ago
Last modified 4 months ago
#35508 assigned New feature
Add an --ignore-deps flag to squashmigrations
Reported by: | Shai Berger | Owned by: | Clinton Christian |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Normal | Keywords: | squash squashmigrations |
Cc: | Mariusz Felisiak, David Wobrock, David Sanders, Andrew Godwin | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | yes | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
In large, long-going projects -- the ones whose need for migration squashing is the greatest -- apps have a tendency to develop dependencies upon each other. This entails problems with migrations -- dependencies could be circular, or an app could be removed from the project but the migrations that hold dependencies on it still remain, and squashmigrations
faces constraints that makes it very hard to do correctly. Current implementation often generates migrations that make no sense, with dependencies on several migrations from the same app.
As a partial solution, let's add a --ignore-deps
flag to squashmigrations
. When this flag is applied, the generated squashed migration will
- Only depend on the dependencies of the first migration in the range squashed
- Not include the operations that create or modify relation fields, if these fields refer to models from other apps (deletion can be included)
The idea is that such a migration will be correct, but not complete. Assuming the range of migrations includes the last migrations of the app, it will then be possible to add the missing pieces by a regular makemigrations
; but the squashing will still include all the non-ellidable RunSQL
and RunPython
operations -- the squashmigrations --ignore-deps
+ makemigrations
dance is proposed as a safer alternative to "migration bankruptcy", the practice of just removing all the migrations and stating afresh
On a side note: It may be safer to add an operation which enforces that it is indeed called with the last migration of the app in range, and maybe even automatically invokes the following makemigrations
, but I think we should trust developers with the lower-level building bricks, which may be useful in other situations as well.
This follows from a discussion on the forum.
Change History (5)
comment:1 by , 4 months ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 4 months ago
Cc: | added |
---|---|
Triage Stage: | Unreviewed → Accepted |
Hi Shai, thank you for raising this ticket
cc-ing a few people here in case they have further insights or opinions on this
Tentatively accepting as the discussion seems positive and I can see the value of the feature 👍
comment:4 by , 4 months ago
Has patch: | set |
---|
comment:5 by , 4 months ago
Filtering out multi-app FieldOperation
s is pretty straight forward, but should we mutate a ModelOperation
to exclude multi-app foreign key references, or exclude the ModelOperation
entirely?
I'm working on this and will finalize a PR shortly. However, does this have to be reviewed by a core member in order for the PR to be accepted?