[Django] #24669: Migrations should only be marked as run on "their" db
Django
--------------------------------+--------------------
Reporter: simonpercivall | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+--------------------
We're using a multi database setup. Each db will have all migrations
written to the "django_migrations" table, even if the migration doesn't
apply to that db. Also, state is calculated for each migration, even when,
again, that migration doesn't apply.
It'd (for the writing of migrations to the db) be less confusing and
cleaner to write only applicable migrations to "django_migrations". And it
would be faster if state were to be calculated only when necessary. As it
is, building up state for all models takes a considerable amount of time
when running migrations on a "non-default" database where we only have a
few tables.
--
Ticket URL: <https://code.djangoproject.com/ticket/24669>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: simonpercivall | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.7
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by knbk):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Hi Simon,
With the way things work now, we don't know if a migration has to be
applied to a specific database, we only know if an operation applies to a
database. Furthermore, the router that determines this depends on the
current state of the model at that point in the migrations. In most cases
it won't matter which historical state is passed, but because we pass that
specific state (and need to, to maintain backwards compatibility), it is
not trivial to know if a migration needs to run on a specific database.
Quite a few optimizations have made it to 1.8, and we will continue to
optimize it (1.8.1 introduces a massive improvement in model state
rendering). If you have a lot of migrations, squashing them will also help
to speed things up considerably.
Your proposal makes sense, but I think it will require a substantial
amount of work. I might underestimate the amount of multi-db setups, but I
don't think it's worth it at the moment. I also think there are still some
significant improvements to be made to the general case. If this is a
major point for you, you are of course more than welcome to work on it.
--
Ticket URL: <https://code.djangoproject.com/ticket/24669#comment:1>
Django
Reporter: simonpercivall | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/24669#comment:2>