class MigrationExecutor:
Method | __init__ |
Undocumented |
Method | _create_project_state |
Create a project state including all the applications without migrations and applied migrations if with_applied_migrations=True. |
Method | _migrate_all_backwards |
Take a list of 2-tuples of the form (migration instance, True) and unapply them in reverse order they occur in the full_plan. |
Method | _migrate_all_forwards |
Take a list of 2-tuples of the form (migration instance, False) and apply them in the order they occur in the full_plan. |
Method | apply_migration |
Run a migration forwards. |
Method | check_replacements |
Mark replacement migrations applied if their replaced set all are. |
Method | detect_soft_applied |
Test whether a migration has been implicitly applied - that the tables or columns it would create exist. This is intended only for use on initial migrations (as it only looks for CreateModel and AddField). |
Method | migrate |
Migrate the database up to the given targets. |
Method | migration_plan |
Given a set of targets, return a list of (Migration instance, backwards?). |
Method | record_migration |
Undocumented |
Method | unapply_migration |
Run a migration backwards. |
Instance Variable | connection |
Undocumented |
Instance Variable | loader |
Undocumented |
Instance Variable | progress_callback |
Undocumented |
Instance Variable | recorder |
Undocumented |
Take a list of 2-tuples of the form (migration instance, True) and unapply them in reverse order they occur in the full_plan.
Since unapplying a migration requires the project state prior to that migration, Django will compute the migration states before each of them in a first run over the plan and then unapply them in a second run over the plan.
Mark replacement migrations applied if their replaced set all are.
Do this unconditionally on every migrate, rather than just when migrations are applied or unapplied, to correctly handle the case when a new squash migration is pushed to a deployment that already had all its replaced migrations applied. In this case no new migration will be applied, but the applied state of the squashed migration must be maintained.
Migrate the database up to the given targets.
Django first needs to create all project states before a migration is (un)applied and in a second step run all the database operations.