Django-migration-linter

Latest version: v5.1.0

Safety actively analyzes 630052 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 4 of 7

1.4.1

Update testing dependencies (`mysqlclient`, Django 2.2 and `black`)

1.4.0

* Add `--include-migrations-from` option to only consider migrations specified in a given file. No matter if the migrations are selected from a git commit or not, we only select the ones in the given file.
* Add `--quiet {ok,ignore,error}` option to remove different or multiple types of messages from being printed to stdout.
* Make detection of problematic table and column a bit more resilient for UX.
* Add Python 3.8 to test matrix and update test dependencies.

Fixed bugs:
* Handle adding many to many fields correctly.

1.3.0

* Add `--exclude-migration-tests` option to ignore backward incompatible migration tests.
* Do not falsely detect dropping `NOT NULL` constraint.
* Detect `DROP TABLE` backward incompatible migration.
* Detect adding a `UNIQUE` constraint as backward incompatible migration.
* Handle when Django tries to generate the SQL of a migration but raises an exception because
it cannot find the name of a certain constraint (because it has been dropped already).

Internal change:

* Differentiate different database vendors during SQL analysis.

1.2.0

* Add `--unapplied-migrations` and `--applied-migrations` mutually exclusive options
in order to respectively lint only unapplied or applied migrations.
* When loading migration starting from a git ref, cross the found migrations
with the currently loaded migrations in the project.
* Add `--project-root-path` which allows to specify the root path
which is used for finding the `.git` folder. (thanks to linuxmaniac)

1.1.0

* Improve speed of ignored migration through the `IgnoreMigration` operation.
Instead of generating their SQL, we verify if the Operation class is present.
Thus we don't have to wait for the SQL generation. Also improves the caching strategy.

Breaks some internal APIs, so minor update to 1.1.0.

1.0.0

**Breaking changes of the linter usage**.

The linter now is a Django management command.
It should be used with a `python manage.py lintmigrations` followed by the usual options.
Additionally, the linter now needs to be added the to the `INSTALLED_APPS` in your Django settings.

* The linter is now much faster: we don't setup django once for each migration
* The linter is now more robust: we rely on Django internals to discover migrations
* Clean up of the testing setup: it is cleaner, less brittle and we have more confidence that it works
* Added support for Django 2.2
* Dropped support for Python 3.4

Fixed bugs:

* Made the cache database-dependent. Between multiple databases, some migrations would be considered correct while they are not on the used DB.
* Adding an erroneous migration to the ignore list on the second run would get the migration content from the cache and not ignore it.

Page 4 of 7

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.