Do not suppress sqlmigrate errors

Now, if an error occurs while executing the sqlmigrate command, then as a result, the analyzer will be given an empty string instead of migrations SQL. This can cause a backwards incompatible migration to get into production and break it.

https://github.com/3YOURMIND/django-migration-linter/blob/76a55dbb128f6f4cddc320624d42f3e67ea4c9bd/django_migration_linter/migration_linter.py#L295-L318

The suggestion is to add a strict check option to require the sqlmigrate command to be run for migration.

[David-Wobrock]

That’s a very interesting use case! Thanks for sharing that 😃

After a bit of reflection, this is definitely a case we want to avoid. We want the linter to be reliable, and I’d prefer it to be over cautious and warn the user that the migration could be problematic, but it can’t say for sure, than to silently consider the migration as valid. I’ll write a patch to change this, and this will probably mark the next major release for the linter 😃

[David-Wobrock]

First, just for the record (and so that I don’t forget it 😛) it’s a known bug in Django: https://code.djangoproject.com/ticket/26624.

But in short, I have a model like:

from django.db import models


class MyModel(models.Model):
    x = models.IntegerField()
    y = models.IntegerField()

    class Meta:
        unique_together = ("x", "y")

and create a migration. Then, if we change the unique_together and inverse the columns for instance (so that we need to drop and recreate the constraint) we have a new migration

    operations = [
        migrations.AlterUniqueTogether(
            name='mymodel',
            unique_together={('y', 'x')},
        ),
    ]

The sqlmigrate of this migration fails if the one creating the unique_together was not applied (the error is ValueError: Found wrong number (0) of constraints for app_remove_constraint_mymodel(x, y)). But if we run the first migration, then the sqlmigrate gives us:

BEGIN;
--
-- Alter unique_together for mymodel (1 constraint(s))
--
ALTER TABLE "app_remove_constraint_mymodel" DROP CONSTRAINT "app_remove_constraint_mymodel_x_y_af56469c_uniq";
ALTER TABLE "app_remove_constraint_mymodel" ADD CONSTRAINT "app_remove_constraint_mymodel_y_x_62eaf196_uniq" UNIQUE ("y", "x");
COMMIT;

So the issue is that, on a project where all migrations are linted but not applied (maybe on a CI build), there is a high change that at least one migration will fail like this I think.

I would actually also lean towards option (1), as it is the option where the linter is doing the least “magic”. So letting, by default, the error raise but with a specific message from the linter giving some indications what to do could be viable in my opinion 🤔 But giving an easy possibility to ignore this migration (and more or less fallback on the previous behaviour).