#36992: Migrations that belong to apps that are always routed to different
databases can be shortcut to be "faked" earlier
-------------------------------------+-------------------------------------
Reporter: Suzannah Cooper | Type:
| Cleanup/optimization
Status: new | Component:
| Migrations
Version: 6.0 | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
One usage of routers is to be able to say which database tables within a
Django app should be routed to. Within the application I am working on, we
have an implementation of `allow_migrate` which takes in the `app_label`
and database and always returns `False` if it is for an `app_label` that
should go to a different database.
I've been working within a large Django codebase, which has many
migrations (that should have been squashed, but for whatever reason have
not been squashed yet). We have been setting up another database. Django
requires that all the migrations that are routed to the default database
also be applied on this new database. Given that those old migrations
should never be routed, we expected these to only be no-ops and performing
an insert to show that the migration has been marked as completed.
When profiling locally with a sample size of ~3000 migrations that would
always be routed elsewhere, we found that the
`executor.py::apply_migration` function was taking up a large chunk of the
time. For example, this took somewhere in the realm of half an hour to run
all migrations. The `migration.apply(state, schema_editor)` is where the
`allow_migrate` function was being checked within, another few function
calls deep, within the migration `database_forwards` logic itself.
When we added a check for `allow_migrate` within the `apply_migration`
function, skipping the `migration.apply` if `allow_migrate` returned
False, we had a speedup so significant that it changed from the order of
an hour or so to a minute.
Attaching some profiled logs screenshots for the individual functions. Can
provide more upon request
--
Ticket URL: <https://code.djangoproject.com/ticket/36992>
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 view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019cffac42e3-fe42666b-9be0-4b96-ad5e-04d3916797f9-000000%40eu-central-1.amazonses.com.
