django-migration-linter is a tool for Django projects designed to detect backward incompatible database migrations. It analyzes new migrations against a baseline (e.g., a Git branch) to prevent accidental breaking changes to your database schema. The current version is 6.0.0, and it maintains an active release cadence, frequently adding support for new Python and Django versions.
pip install django-migration-linterNo compatibility data collected yet for this library.
To quickly use `django-migration-linter`, add it to your `INSTALLED_APPS` and then execute the `lintmigrations` management command. The example demonstrates how to run the linter to compare migrations in your current branch against the 'main' branch, ensuring that any detected warnings will cause the command to fail. This is typically run in CI/CD pipelines.
No direct code change is typically needed unless your specific setup or scripts relied on the old behavior for custom-labeled apps. Ensure your `django_migration_linter` configuration and expectations align with app labels.
Ensure your environment (e.g., CI/CD) provides a correctly configured and accessible database for `sqlmigrate` to run successfully. Address any underlying issues causing `sqlmigrate` errors. If an error is truly ignorable (rare), you can use the `--ignore-sqlmigrate-errors` option (available from v5.1.0 and later).
Update any scripts or CI/CD configurations that invoke `manage.py lintmigrations` to use the new argument syntax, for example: `manage.py lintmigrations --git-commit-id <commit_id>`.
Ensure your environment where `lintmigrations` is run (e.g., local development, CI/CD pipeline) has a valid database connection configured in Django settings. You can use a lightweight database like SQLite for testing purposes if full database functionality isn't strictly needed for the SQL analysis.
Always consult the specific release notes for the `django-migration-linter` version you intend to use to confirm compatibility with your project's Python and Django versions. Upgrade your Python/Django stack if it falls outside the supported range for the desired linter version.
To resolve this, make the column nullable initially, set a database-level default (e.g., using Django 5.0's `db_default`), or populate existing rows with a default value using `RunPython` before making the column non-nullable in a separate migration step.
Implement a multi-step deployment: first, remove all application code references to the table, deploy, and only in a subsequent deployment, create a migration to drop the table.
Perform a multi-step table rename: first, create a new table with the desired name, migrate data from the old to the new table, update application code to use the new table, and only then drop the old table in a later deployment.
Replace direct model imports with `MyModel = apps.get_model('app_label', 'MyModel')` to ensure the migration operates on the historical model state at that point in the migration history.