Django Migratron is a schema migration tool for Django. Why write another schema migration tool? Here is how we stack up against other tools.
pip install pytz PyYAML django-yamlfield termcolor django-migratron.
migratron to the INSTALLED_APPS setting:
You can configure the following settings in your
settings.py. All of these are optional, if you don't specify them, they will use defaults.
MIGRATIONS_DIR- The directory where migrations will be stored either at the top level, or in top-level directories corresponding to migration types.
Different migration types might be things like "pre", "post", "delayed", etc.
You can use an absolute path, or build one dynamically like so:
MIGRATIONS_ALLOWED_TYPES- A tuple of allowed migration types. If not specified, any type is allowed, including no type. To explicitly allow no type (ie, migrations in the root directory), add None to the tuple.
MIGRATIONS_SCRIPT_AUTHOR_LINK_FUNCTION- The function to run on a file path to get the script commit link (ie, github, bitbucket, etc).
MIGRATIONS_TIMEZONE- The timezone used to calculate the display value of the script run datetimes in --list.
MIGRATIONS_DBSHELL_CMD- The command to run to exclude
manage.py dbshell, but you may use an alternate shell, or an alternate python intepreter.
Migrations are created based on python/sql templates. The body of the script must be implemented manually. The templates have standard meta-data slots in them, in the form of a leading comment block.
./manage.py createmigration "Add date_added and user columns to the Foobar model- Create a new python migration
./manage.py createmigration --type pre "Add date_added and user columns to the Foobar model- Create a new python migration of type "pre"
./manage.py createmigration --template sql "Add date_added and user columns to the Foobar model- Create a new sql migration
./manage.py migrate --list- List the migrations under the root
./manage.py migrate --type pre --list- List the migrations under the
./manage.py migrate foobar.py- Run the migration
./manage.py migrate --type pre foobar.py- Run the migration
./manage.py migrate --all- Run ALL migrations in
./manage.py migrate foobar.py --log-only- Don't really run the migration, but add it to the migration history as successfully run
./manage.py migrate foobar.py --delete-log- Delete the migration history for this file
./manage.py migrate foobar.py --pending- Exit with status code 1 if there are pending migrations
./manage.py migrate foobar.py --info- Print all meta-data, migration history and notes for a migration.
./manage.py migrate foobar.py --notes- Create or edit the migration runner's note for the latest migration using $EDITOR.
./manage.py migrate --list --verbose- List migrations with extra meta-data, like runner's notes.
./manage.py migrate test.py --flag "Need to run this again after the next deploy"- Flag a migration as needing further attention, with an optional note.
./manage.py migrate test.py --flag- Toggle the flag on an existing migration.
./manage.py migrate test.py --clear- Delete all migration history from the database.
If you need to play back sql migrations run on one database against another one, you may find it useful to list migrations in the order they were actually run, optionally with runner comments. For history commands, types do not matter; all run migrations are output.
./manage.py migrate --history- List just the file names in the order they were run.
./manage.py migrate --history --verbose- List file names and runner comments.
If you want to require manual confirmation for a particular migration, just make sure you exit with an error code, or raise an exception, if the script does not run. That way, the script will not be marked as having run successfully.