Problem: Previously in gh-117 we aimed to solve gh-115, which described a problem where we used `SET DEFAULT` and then `DROP DEFAULT` immediately afterward. The solution was to track whether any defaults are retained, but the `ends_with_default` variable is initialized as `None` rather than `False`. At the end of the function we check whether `ends_with_default is False`, never occurs unless a default is set.
Solution: Assume that there is no default unless proven otherwise, and iniitializie `ends_with_default` to `False` instead of `None`.
Fixes: gh-158
It now allows:
* get_model(...) calls with one parameter only
* allows the variable name to be not the same as the model name itself (this will become a warning)
* Misspelled filename => fail (instead of linting all migrations and ignoring the error)
* An empty file/a file with no valid migration paths => lint no migrations (instead oflinting all migrations)
* If the option is not specified, keep the behaviour of linting all migrations
Instead of using the file path when the git commit is not
added, use the file and the migrations list no matter if we select
all migrations or just from a certain git commit.
And unit tests :)
Tests that running the linter a second time by ignoring an erroneous migration
will not hit the cache for the said migration.
Instead, it is correctly ignored.
* don't use the project fixtures anymore but the one Django project
* update and refactor cache tests to be less brittle
* explicitly test mysql, postgresql and sqlite3 databases
* remove 'multiple_call' tests since it is not possible anymore
(with the Django singleton)
* update Travis and tox (dropping Python 3.4)
* manage.py file at the root of the project
* targetting the project located at tests/test_project/settings.py
That allows testing the linter through just calling it on the project itself.
Using the new method coming soon: `python manage.py lintmigrations`
Christian Bundy
David Wobrock
Viktor Danyliuk
Tobias Kroenke