Nullable bool with default value [contrib?]

[MJohnsson]

I have an issue where the below property is always returned as "true" even if it's null in the db. I guess this is due to the default value, but default values shouldn't override what's in the db - or so I thought.

Part of model..
public bool? SolvedByCalldesk { get; set; } = true;

Part of Contrib-call..

...
var returnTask = connection.GetAsync<T>(id);
//caching here
result = await returnTask;
...

I've verified that the DB-record in question is null, but "result" returns it as true. Is this intended?

[EminemJK]

No， you can try deleting
= true;
=>
public bool? SolvedByCalldesk { get; set; }
and see what happens

[NickCraver]

It is indeed behaving as intended. You can use a constructor approach instead if you want to override the behavior (just have a constructor that matches the columns you're pulling back) if you want complete control here :)

[mcrepssdi]

This is not a correct answer when your object has over 200 parameters. Why would Dapper ignore nulls when reading from a DB. Was the intent for Dapper to only be used with a modern database and not a legacy database?

[mgravell]

In many cases in Dapper "core", an important consideration is simply: changing this globally is basically impossible without breaking huge numbers of people, and offering per-location configuration is very complicated. If we want to do something here, I would suggest (as per #1909) that this is a feature that could be implemented much more sensibly in DapperAOT, possibly via a new property on [DbValue], or possibly as a new bespoke attribute that could be applied at multiple levels (field/property/type/module/etc). Your Dapper code doesn't change, other than to turn it on. If this is of interest, I would suggest logging it over there