1

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?

Mackan
  • 6,200
  • 2
  • 25
  • 45

1 Answers1

0

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.

Mackan
  • 6,200
  • 2
  • 25
  • 45