This might be a bit of an edge case, and maybe I'm wrong in my understanding of how default values work in this case.
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 Dapper.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 a problem with me, dapper or just how it works with default values on nullable types?
I received a response to this issue on Dappers github:
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 :)
So any null in the database would use the default value in the model, rather than the database value (even if record existed and null is a valid value for the property/field).
It makes sense why it's handled like this, but at the same time it's not totally correct i.m.o.