Post #1860156
2026-04-28 16:48 UTC
Replies (14)
-
@janmaltegerth@mastodon.social 2026-04-28 16:59
@davidism@mas.to we use notnullable default empty and verify this by flake8 / ruff pre-commit checks https://docs.astral.sh/ruff/rules/django-nullable-model-string-field/
-
@Crocmagnon@fosstodon.org 2026-04-28 17:08
@davidism@mas.to I’d say it depends whether you need to differentiate between « no value » and « empty string » at any point. If not, then you end up with two values for « nothing » which is annoying. In any case, « nullable, default empty string » seems like a bad idea. I’d vote for « not nullable, default empty string » unless there’s specific reasons to differentiate null values.
-
@phryk@mastodon.social 2026-04-28 17:14
@davidism@mas.to Nullable with default null, then implement handling for it in the form validation/coercion layer. It's cleaner from a data model perspective and I tend to treat that as the ground truth most other things are based around. I've seen another person in this thread advocate default empty string saying you otherwise *might* have two different "empty" values (if you don't distinguish between null and ''), but with that you *definitely* introduce a different empty value ('') based on type.
-
@kaleissin@wandering.shop 2026-04-28 17:50
@davidism@mas.to I would prefer the top one, because of the magic of NULL in SQL. For instance, NULL is unique, which affects indexes quite a bit. I'm using Django though, so rarely break out the NullableCharField.
-
@BoydStephenSmithJr@hachyderm.io 2026-04-28 18:15
@davidism@mas.to I voted "not nullable, default empty", but I actually do "not nullable, no default" and have the app insert the empty string explicitly. I try to make every column not nullable if possible. I rarely see value in providing a default at the DB layer, tho it is possible.
-
@studiop@fosstodon.org 2026-04-28 18:16
@davidism@mas.to if it weren't for the HTML form submitting empty string instead of null I would say make it nullable default None to differentiate between null and empty. Once you've lost that context with the form submission it's moot point IMO.
-
@HaraldKi@nrw.social 2026-04-28 19:15
@davidism@mas.to An empty string is still a string. If you are absolutely, totally, abysmally, ultimately, eternally sure your application does not need the empty string, you may use it to represent the absence of a string. This has nothing to do with how you display either or serialize them into network messages, but has primarily to do with what the application or domain logic requires. Everything else has to follow.
-
@dws@infosec.exchange 2026-04-28 19:45
@davidism@mas.to Allowing for null distinguishes between not knowing a thing and knowing that it's nothing. What to display in the UI is a policy decision the app gets to make.
-
@glyph@mastodon.social 2026-04-28 19:55
@davidism@mas.to oh man there is a huge load-bearing "it depends" on this one. if it's user input from something standard-HTML-form-like where there's no semantic distinction between null and empty then not nullable, no default, but take the empty string from the input (no need to create an "empty" draft in this case, the browser does it for us). if there's a way to indicate the null-ness of the field to the user, then nullable default null because insert-empty-accept-defaults is a convenient draft
-
@andy47@aus.social 2026-04-29 01:34
I love the concept of Null in a relational database (#RDBMS), but it’s tricky to understand and even tricker to get right every time. Context is everything. The trick is to remember is that you can’t do a comparison (=) to a Null value, SQL has a special operator (IS NULL or IS NOT NULL) to deal with them.
-
@paulox@fosstodon.org 2026-04-30 22:49
@davidism@mas.to 👇 > Avoid using null on string-based fields such as CharField and TextField. The #Django convention is to use an empty string, not NULL, as the “no data” state for string-based fields. If a string-based field has null=False, empty strings can still be saved for “no data”. If a string-based field has null=True, that means it has two possible values for “no data”: NULL, and the empty string. In most cases, it’s redundant to have two possible values for “no data”. https://docs.djangoproject.com/en/stable/ref/models/fields/#django.db.models.Field.null
-
@mistersql@mastodon.social 2026-04-30 23:00
@davidism@mas.to "nothing' is a domain specific concept and null should be used only for the non-domain specific situation of the application pointing to something that should be there but isn't. Databases and programming languages don't particularly follow my rule.
-
@davidfstr@mastodon.world 2026-05-01 17:05
@davidism@mas.to I chose "not nullable, default empty string" because I prefer data models where there is only 1 empty/error value. -- A comment situation where there are multiple empty/error values (to my dismay) is JavaScript, with its 2 sentinels: null and undefined.
-
@davepeck@mastodon.davepeck.org 2026-05-04 02:46
@davidism@mas.to My instinct (and, when possible, implementation) is always nullable, default null. Django long ago decided the answer is empty string, so when I happen to be in that ecosystem I demure.