null == "" is true? (page 4)

On Tuesday, 19 July 2022 at 16:55:39 UTC, Kagamin wrote:

As I understand, in your scenario there's no difference between null string and empty string, they both work like empty string, and D treats them as empty string. That's what I mean when I said that distinction between null and empty is meaningless.

Sorry Kagamin... I dindn't read this comment and I added a very large answer to the next one that has no sense :-p. I miss being able to delete answers from the forum :-)

Yes... I decided to treat the same way internally for strings.

Previously

DtoVal!(Null, string)( null) was equivalent to DtoVal!(Null,string)( Null() )
DtoVal!(Null, Person)( null) was equivalent to DtoVal!(Null,string)( Null() )

Currently

DtoVal!(Null, string)( null ) is equivalent to DtoVal!(Null,string)( "" );
For other types this will raise a runtime exception: DtoVal!(Null, Person)( null ).
- The correct way of is DtoVal!(Null, Person)( Null() )

Basically, null is completely useless and out of my code with the exception of strings.

Best regards
Antonio

July 20, 2022

Re: null == "" is true?

Posted by Antonio
in reply to Kagamin

Permalink

Antonio

Posted in reply to Kagamin

Permalink

On Wednesday, 20 July 2022 at 13:35:14 UTC, Kagamin wrote:

On Tuesday, 19 July 2022 at 18:05:34 UTC, Antonio wrote:

In a relational database, NULL is not the same that ""... and NULL is not the same that 0. Are semantically different and there are database invariants (like foreign keys) based on it. Trying to "mix" this concepts in a database is a mistake.

So, it's an implementation detail or a relational database that leaks into business logic because nobody thought about it? Just because a relational database has many features, it doesn't mean business logic must use them all, it must use only what makes sense for business logic.

It is not about "so many fetaures"... it is about entity model and how relational database stores it. General purpose programming languages include their own representation to the NULL concept that is not "relational model" dependent: Optional, Maybe, Nullable, Union types

What semantics your domain models implement? Is it semantics of all features of a relational database or is semantics of business logic?

Database is an strict repository: it stores the entity model with relational semantics including strict invariant management (primary keys, foreign keys, field types, nullablility, ...) and following normalization rules (3th normal form, at least). It is, basically, a "consistent" model.

Business logic trust on database repository invariants and implements whatever your Business Model require (i.e.: complex model operations involving multiple repository operations). Business works using Objects/Entities of the domain and it is required a way to map this to relational model (ORM or manual SQL)... Usually in a specific "Data" or "DAO" layer. Transactions are your friend (The only way to ensure that high level invariants are enforced)

If you can't be confident with database invariants (because you are using NoSQL repository like MongoDB or DynamoDB or an Old ISAM MySQL or "trash" models over relational engine) then you need to "move" all these "consistency" control to the business layer developing workflows/processes that must be ready to work with "inconsistent" data... (You can read this article I wrote 2 years ago about SQL/NoSQL solutions and Brewer's conjecture: https://qr.ae/pvklQA)

Business "architecture" based on a single repository is the simplest one... But the pleasure of trusting on a relational database is always welcome.

Forums