Timeline for Validating data classes with nullable properties that should never be null
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 16, 2023 at 13:34 | comment | added | gnasher729 | @GregBurghardt If you use JSON it could be worse. In a dictionary, you might want to access a string by key. The possibilities are: Key is not present. Key is present and the value is explicitely null. Key is present and the value is an empty string. In theory, they might all mean different things. | |
| Aug 16, 2023 at 11:01 | history | edited | Doc Brown | CC BY-SA 4.0 | added 72 characters in body |
| Aug 15, 2023 at 20:24 | comment | added | Doc Brown | @GregBurghardt: my point is, regardless whether a DB technically makes a difference between NULL and the empty string. for most real world use cases and domains I know, the distinction isn't important. Hence, the typical domain class doesn't need many string? attributes, just string atttributes which might be empty. Of course, an ORM which generates DTOs from some table definition, using string? for each nullable column, might force you to deal with null values, but typically only once at construction time. | |
| Aug 15, 2023 at 17:53 | comment | added | Greg Burghardt | The only caveat to rarely being required to distinguish between a null string and "" is Microsoft SQL Server. Frustratingly, it does distinguish between a null value and an empty string for certain data types. This was a surprise to me when migrating from an Oracle database to SQL server, because our code blissfully sent "" to the database and expecting a null back. That's not what we got, though. We got "" instead. This all depends on how you interpret a null string versus an empty string. | |
| Aug 15, 2023 at 16:46 | history | answered | Doc Brown | CC BY-SA 4.0 |