Add knowledge of Django Migrations and tracking of the schema upgrade method.
Review Request #10550 — Created May 13, 2019 and submitted
One of the major pillars of Django Evolution 1.0 is compatibility with
Django's built-in schema migrations. Apps that use Migrations need to
not be tracked for evolutions, and legacy apps using evolutions need to
be able to transition to migrations.This change adds the beginnings of the Migrations support. It introduces
a concept of an upgrade method (evolutions, migrations, or
undetermined), which can be computed from an app based on the presence
of evolutions or migrations submodules and whether an evolution
transitions the app to migrations.Transitioning is done through a new
MoveToDjangoMigrations
mutation.
Once applied to an app, further evolutions are no longer allowed on that
app, only migrations. This allows a starting migration to be specified,
defaulting to the standard "0001_initial" used by migrations. This
is intended for theoretical specialized cases where an app may have
supported both migrations and evolutions, resulting in a common branch
point for further migrations. It's also intended for future work that
could allow an app to transition back to evolutions and then back to
migrations. Basically, future expansion.This upgrade method is stored in the signature and included in diffs.
Apps that appear to have gone from evolutions to migrations will be
shown in hints. The signature also tracks the last migration ID applied
to an app using migrations. Currently, that's always going to beNone
,
but this will be used later when the evolver is ready to manage
migrations.
Unit tests pass for Django 1.6 and 1.11 and on Python 2.7 and 3.7.
Tested locally with an attempted upgrade simulation from Review Board
3.0 to 4.0 on Django 1.11. This included a mix of apps using evolutions
to upgrade, apps using migrations, and apps that were using evolutions
but move to migrations usingMoveToDjangoMigrations
. Saw the simulation
results I expected.
Description | From | Last Updated |
---|---|---|
E127 continuation line over-indented for visual indent |
reviewbot | |
E722 do not use bare except' |
reviewbot | |
Migrations shouldn't be capitalized here. |
david | |
Migrations shouldn't be capitalized here. |
david | |
Migrations shouldn't be capitalized here. |
david | |
Migrations shouldn't be capitalized here. |
david | |
Hmm. Shouldn't this say can't be resolved by evolutions? |
david | |
Migrations shouldn't be capitalized here. |
david | |
And here. |
david | |
And here. |
david | |
abcvd |
TS tstedman | |
pop |
TS tstedman |
- Change Summary:
-
Fixed Review Bot complaints.
- Commit:
-
0b49f59620dda3799a8e588d3d3c49afc831479c23f71545e966ba9ff1004abefea4c9be63c49ab8
Checks run (2 succeeded)
-
This looks quite good. Most of my comments here regard the capitalization of "migrations", which is inconsistent throughout. Django's docs don't capitalize it, so I don't think we should (except of course where it's sentence capitalized).
-
-
-
-
-
-
-
-