Adding a unique UUIDField to an existing model immediately fails with a database constraint error

[Tom Forbes]

If you want to add a unique UUIDField to an existing model, you would add the following field definition (as per the docs):

column = models.UUIDField(unique=True, default=uuid.uuid4)

However, upon creating and running a migration Django calls the default function *once*, then attempts to update all rows in a single query, which obviously violates the unique constraint and throws a database error.

This is particularly annoying and possibly confusing to new users (the error message is not exactly descriptive), and there does not seem to be an easy way of overriding it without creating your own custom RunPython migrations that sequentially calls the default function for each row.

Because it's pretty common to have a unique UUIDField, and because it's a problem you immediately run into when adding it to an existing model, could a workaround be added in the migrations framework to be a bit smarter about this? Or perhaps in a more generic sense, if unique=True then re-evaluate the default for each row rather than once during an UPDATE statement.

[Tim Graham]

Duplicate of #23932 where the decision was to ​document the solution. If you want to revisit the design decision, feel free to offer a proof of concept on the DevelopersMailingList.