Ok so that is acceptable (I put question marks because I hadn't checked behaviour in that case). But the other two cases I listed:
- AddField without `blank=True` or `null=True`.
- AlterField [removing `null=True`] AND [removing `blank=True` OR already not having `blank=True`]
calls the questioner.
In its current state I don't like this because:
(1) Whether or not the questioner (a backend helper) opens depends on `blank` (a frontend validation option).
(2) The questioner phrases itself as you trying to do something erroneous ('you can't do this'), when it's a valid thing to want to do.
The behaviour in (1) threw me when i first stumbled across it, as I hadn't expected `blank` to have any effect on making migrations. Tim has kind of convinced me to accept it, just because it's the 'usual' scenario and makes things convenient. Plus, fixing this would either mean reverting
#23405 (bad option), or dropping the questioner altogether (correctness over convenience; not a great option either).
Alternatively, could try to address (2) by making the questioner less scary: 'Are you sure?/maybe you'd like to set a one-time default instead?' over 'you can't do this; set a default or quit'.
So I think if anything comes of this, it'd likely just be a slight rewording of the questioner and an additional choice being added. This wouldn't offer any new functionality, as choosing 'yes, I'm sure I want to set existing rows to emptystring' would be equivalent to choosing 'set a one-time default' and entering emptystring manually. But the difference would be that the user doesn't feel like they've done something wrong when they see this. I can say from experience, whenever I saw the questioner in the past, I quickly cancelled it and went back to try and fix up my models, assuming I'd made a mistake.
Cheers,
Jarek