#25530: Deferred foreign keys operations fail when the column is changed during
the
same migration
------------------------------+------------------------------------
Reporter: simonphilips | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
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
------------------------------+------------------------------------
Changes (by shaib):
* cc: shaib (added)
Comment:
Replying to [comment:4 simonphilips]:
> What is the reason for delaying these SQL statements until after all
operations have run? Why are they not run right after each operation?
Think about a migration which adds two models to an app: a model `A`, and
a model `B` with a FK to `A`. If `A` is created first, there's no problem,
but if `B` is created first, then you can't add its foreign-key constraint
until `A` is created. So, to run the statements immediately with the
operation, you'd have to trace such dependencies and make sure models are
created in the right order; this would be doable in the migration
generator, but a bit of a chore if you write migrations by hand.
Now consider a case where there is a "loop" of FKs (`A` has a FK to `B` as
well); there is no order of creating the models that will work -- you must
separate out the constraint creation statements.
Since the "loop" case is valid, and a solution for it already handles the
cases that would be solved by tracing FK dependencies, the solution was
adopted across the board: Some statements are generated as "deferred" and
are only executed at the end of the migration.
With that explanation in mind, your suggestion in the ticket -- to add an
operation to "flush" the deferred statements, and put it in between
original migrations when squashing, makes a lot of sense. There is a
problem with that: Such an operation could seriously mess with the
optimizer. A possible solution would be to insert the operation only
before `Run{Python,SQL}` operations which block the optimizer anyway.
Adding an operation (whether implicitly or explicitly) would count as a
new feature, and either way the problem is not a regression nor a major
failure in a new feature in 1.8. If a solution can be found without new
behavior, it might be accepted into 1.9, otherwise, it can only go in
1.10.
--
Ticket URL: <https://code.djangoproject.com/ticket/25530#comment:6>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/070.18075837a2614456d1341415ce8fdcf3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
