Migrations with `default=some_callable` populate all existing rows with the same value

[Stavros Korokithakis]

A migration that adds a field with default=some_func run that function once and then use the value as the default for the new rows. This fact is [documented](​https://docs.djangoproject.com/en/2.0/howto/writing-migrations/#migrations-that-add-unique-fields), though still surprising.

I propose that makemigrations either issues a warning when a field with a default=callable is encountered, or, better yet, that it asks what the user intends and generates the three-step migration in the documentation instead. An acceptable solution would also be to generate the three-step migration without asking and then warn about slowness, as that is more in line with users' expectations.

[James Pic]

I don't see why a Django user would add a unique=True,default=callable to a model, and not have a 3 operation migration generated out of the box:

0. add null=True,unique=False,
1. provision new column on each row with the callback,
2. set null=False,unique=True

In terms of software design, this is what i would call a "sane default".

Hence I think this would be a great contribution, let's see what Django experts think about it.

[Stavros Korokithakis]

Replying to James Pic:

I don't see why a Django user would add a unique=True,default=callable to a model, and not have a 3 operation migration generated out of the box:

The only reason I can see if the function is something like datetime.now and the user doesn't want to incur the performance hit. In that case, however, the user could still optimize for speed by editing the migration. I do agree that the three-step migration is the sane default.

[Tim Graham]

Duplicate of #23408