DB: squash migrations #9510
Comments
humitos
added
Improvement
|
In fact, |
|
Commenting the readthedocs.org/readthedocs/settings/dev.py Lines 22 to 25 in bdf154a Why these migrations are run in both databases? In |
Only the migrations from the telemetry app are run, the others are skipped, I assume they are faked, since you'll always see those migrations as applied, but the DB has only the telemetry tables. |
|
This could potentially be a low-hanging fruit. Have your tried quickly to squash @humitos? The typical issue would be that data migrations (stuff with |
|
@benjaoming yeah, I did a quick try and I found that we have some The immediate main issue that I found was the inter-dependency order the migrations need to be run, meaning that we can't squash them all into just one migration per application. I'm not sure how to easily find where they should be split to make this dependency order work fine. |
There is something else happening behind the scenes, because commenting the The verbose output of tox/pytest ( Another thing that I found is that So, there are some work required here that are related but they don't depend each other:
|
Yes, they appear as "run", but only the migrations from the telemetry app are in the telemetry db. This same behavior happens when you first create the docker container for development, all migrations appear in the output as applied, but they aren't really applied in the telemetry db. And I just checked the telemetry db inside a test, and only the telemetry table is there. So I guess django still takes some time to fake those migrations. |
|
Yeah, I'm not saying the tables are created on the telemetry database. I'm saying that the migrations are run twice and consuming the double of time they should |
|
I usually run |
|
@ericholscher I've been testing the |
|
Definitely all the migrations are run one time per database configured. This is how Django works with multiple databases. Then, while running Django decide if the migrations has to be applied to the database or not; but it's run. That's why we are seeing the migrations ran twice but not all tables are not created in Just by running those 2 |
When running tests locally we are executing 252 migrations that consume 33.43 seconds. This is tedious when running just a single test. I think we can reduce this time by squashing all the migrations so we have only one migration per application. What do you think?
Documentation: https://docs.djangoproject.com/en/4.1/topics/migrations/#migration-squashing
The text was updated successfully, but these errors were encountered: