Migration that sets unique nullable field to non-nullable fails

[ivissani]

I've discovered this issue in a project where we are using djangorestframework-api-key.
This package has a migration that creates a CharField with unisque=True and null=True, the populates data for that field and afterwards it sets null=False. This is a pretty common scenario when you need to add non-nullable unique field to a pre-existing model.

Migrations of this kind fail with the following error:
42S11] [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The operation failed because an index or statistics with name 'testapp_testalternullableinuniquefield_a_67b9d427_uniq' already exists on table 'testapp_testalternullableinuniquefield'. (1913) (SQLExecDirectW)

Oddly enough, this only happens the first time django tries to run the migration, but the second time it passes. It is not yet clear to me whether the indexes and constraints are in place after the migration passes.

I've been able consistently to reproduce the error by creating a migration with the following operations:

    operations = [
        migrations.CreateModel(
            name='TestAlterNullableInUniqueField',
            fields=[
                ('a', models.CharField(max_length=50, null=True, unique=True)),
            ],
        ),
        migrations.AlterField(
            model_name='testalternullableinuniquefield',
            name='a',
            field=models.CharField(max_length=50, unique=True),
        )
    ]

I would like to contribute a PR to fix this issue but at this point it is not clear to me how to generate a unit test for the project as I would like to test the migration itself. Any suggestions?

By the way, this error is preventing us from normally run the tests in our project since test database cannot be created due to this error.

[ivissani]

You can take a look at the code in this commit for the example:
ivissani@349e58f

[ivissani]

I have created the following PR #77 that attempts to fix this error (successfully). It is still not clear to me whether the solution should be more general than what I implemented.

[CCattermoul]

Same issue here?
#38

[ivissani]

Same issue here?
#38

I don't think they are the same. Here the problem was that some operations created the constraint right away while others deferred that until the end of the migration therefore resulting in an attempt to create the same constraint twice. This does not seem to be the case of the issue you linked as far as I can see.