I try to avoid nullable strings, so I don’t have to handle an extra scenario: %Email{subject: ""}} %Email{subject: "Hello"} %Email{subject: nil}} # not permitted I thought it was cleaner to allow the string to be whatever length and the empty state is "". This way I never have to first check if it…

[image] dfalling: But I’ve spent the last few hours fighting with Ecto and Changesets interpretation / transformation of empty strings (eg adding a change of name: "" is transformed to name: nil), so I’m curious what other people do. That’s because Ecto deals with that on a completely differe…

[image] dfalling: This way I never have to first check if it’s nil before interacting with it. To add to @LostKobrakai ’s response to this: [image] LostKobrakai: I’d however not consider "" a null value. It’s not the absense of a value, but a string like any other. Even if you went and…

I’ve seen more than one person thrown off by this as well. So the idea that Ecto needs to behave this way is a bit strong. It is a design choice to behave in this manner because many of it users find it to be a good default. But that does throw off/confuse other users.

[image] sodapopcan: When it comes to presenting, in the scenarios where you just want to show a null value as nothing without any special messaging, <%= nil %> works just fine Yeah, though if I want to pass the string to a function, I now need to ensure there’s a base case for nil. Eg, passin…

[image] LostKobrakai: I’d however not consider "" a null value. Agreed. I like the idea of it for fields that always exist but permit empty (I think email subject is the best example for this), but it’s obviously a poor choice for something like user.homepage… in that case I’d expect either a…

[image] dfalling: Eg, passing it to some regex match. So now your regex has to accommodate for empty string which hides the fact that you’re dealing with a nullable field. A nullable field is a nullable field! Ideally most of your fields aren’t but you don’t want to hide it when they are.

[image] sodapopcan: A nullable field is a nullable field! Ideally most of your fields aren’t but you don’t want to hide it when they are. Very true. So I’m guessing the way most people would address this is: can it have an empty state? nullable / nil otherwise: it should be a non-nil strin…

Ya, which is what Ecto Changesets are for! :slight_smile: The other problem you have with "" for email is that now "" is a special case valid email which is going to cause more complicated checks. You either want to have a valid value or nil. That keeps the consuming code simple and mostly focuse…

[image] sodapopcan: The other problem you have with "" for email is that now "" is a special case valid email which is going to cause more complicated checks. Agreed for something like email address. But for something like email.subject, an empty value is valid. So by allowing null for that, …

Ohhhhh boy ok I gotta admit my brain sort of auto-corrected Email to User and subject to email, haha :grimacing: So, rewinding a bit, I’m actually not super opposed to subject being non-nullable with a default of "". It could be argued that an email has three required fields: to, subject, and mess…

How do you model your nullable strings?

Questions & Help Questions

dfalling March 4, 2024, 9:50pm 18

Yep, I was wrong about this. Sorry this was a flurry of comments as I kept trying different things out.