Django Migratron is a schema migration tool for Django. Why write another schema migration tool? Here is how we stack up against other tools.
- Migrations are defined as scripts in a configurable directory
- There are commands to list, run and fake one or more migrations
- Migrations side effects can include schema changes, data updates or anything you can do from python script
- Migration history is stored in the same database that the migrations are run against
- Migrations can be either python or sql files
- Migrations can be placed in a sub directory by type, and you can run/list a single type at a time
- Migrations are not ordered
- Schema migrations cannot be automatically generated
- Schema updates are only as database-independent as you make them
- Migration history includes who ran the migration, when it was run, who authored the script, and any notes either person has entered.
pip install pytz PyYAML django-yamlfield termcolor django-migratron.
Add to INSTALLED_APPS
migratron to the INSTALLED_APPS setting:
Create database tables
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
Listing and Running Migrations
./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.
Confirmation Inside Migrations
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.