id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
27197	Document how blank=True affects the migrations questioner	Jarek Glowacki	nobody	"As a result of #23405, we now have hidden behaviour for the `blank` argument. I support that ticket, but I'd like to debate its use of `blank`.

Recapping that ticket:
If a `CharField` (or `TextField`) is added to an existing model, we can set `blank=True` on it to give all existing rows in the database an empty string. If we don't (assuming we don't set `null=True` either), we'll be forced to either set `default` or pick a value to populate existing rows interactively.

According to the [https://docs.djangoproject.com/en/dev/ref/models/fields/#blank docs], `blank` is supposed to be used for validation only (frontend implied). This was noted [https://code.djangoproject.com/ticket/23405#comment:14 here] in the past, but ultimately dismissed.

It doesn't make sense to check `blank` to decide the fate of existing rows in the db if new rows ''still'' default to emptystring regardless of what `blank` is. If `default` is not provided, existing rows should be assigned emptystring.

Reasoning:
1) If the aim is to draw a parallel with the behaviour of `null=True` for FKs, then there should be a new argument, say, `empty=True`, to denote backend validation for emptystrings. `blank` already has its own meaning and it has nothing to do with the db.
2) If the aim is to try to be helpful to less confident Django users by entering interactive mode if they've forgotten to set `default`, then the undocumented behaviour of `blank` does this no justice and can just lead to more confusion.
3) If the aim is to mimic South then this aim is no longer relevant as South has been gone for several versions now, and Django migrations already behave quite differently to South in many respects. I've never actually used south, but I also suspect its definition of `blank` was not the same as Django's.
4) If the aim is to keep things simple since `blank=True` comes hand in hand with emptystring in most cases, then this is a poor aim, as there should be a distinction between backend and frontend validation (see first point). Further, `blank` is not tied solely to string fields, but to all fields.
5) There should be no difference in population of existing rows and new rows. Otherwise we could make the same argument about `default` affecting existing rows when it should only affect new rows (or vice versa).
6) I hate that I have to set `blank=True` when adding a new CharField, even though it only matters to the `AddField` migration and is completely irrelevant beyond that. Further, my model is left with this cruft for all eternity, lest I remove it and face the interpreter at the next `migrate` call.

So, options:
- [Suggested] Do not check the value of `blank`. If `null=False` and `default` is unset, set all `CharField`s and `TextField`s to emptystring. It's hardly painful to write a migration to populate these later if this was not the user's intention. With this we solidify `blank` as purely a frontend validator. For string-type fields it decides whether or not emptystring is allowed; for related fields it determines whether or not nulls are allowed; etc .. (empty dict for JSONField? idk, haven't checked).
- [Bare minimum] Mention in docs that `blank` has this magical secondary functionality.
- [Meh] Revert #23405 and force `default` to always be set in the absence of `null=True`. I don't see any merit to this, besides perhaps bringing overall consistency in line with `BooleanField`.

Sorry about the long rant, hopefully it makes me come across as passionate about the project rather than fixated on tiny nits. :3"	Cleanup/optimization	closed	Documentation	dev	Normal	wontfix	CharField blank emptystring		Unreviewed	0	0	0	0	0	0