Boolean property with default '1' not working

[POFerro]

Hi :),

I have a SQL server database with a table with bit column not null with default value = '1'
When I scaffold it with EF core 8.0.4 the bool property is no longer nullable as expected.
Yet When I insert a record in the table without filling the bool property it goes to the database with false value = '0' in sql server.
This is the code

var db = new TestEfContext();

db.TestTables.Add(new TestTable { Name = "Test" });
db.SaveChanges();

And my database table is created like this:

CREATE TABLE [dbo].[TestTable] (
    [Id]       INT           IDENTITY (1, 1) NOT NULL,
    [Name]     VARCHAR (200) NOT NULL,
    [TestBool] BIT           CONSTRAINT [DF_TestTable_TestBool] DEFAULT ((1)) NOT NULL,
    CONSTRAINT [PK_TestTable] PRIMARY KEY CLUSTERED ([Id] ASC)
);

Please find attached a small solution with the test console app and the database project.
TestEF.zip

I'm using this configuration
EF Core version: 8.0.4
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .NET 8.0
Operating system: Windows 11
IDE: Visual Studio 2022 17.9.6

Am I missing something, can you help me?
Thanks and best regards
POFerro

[ajcvickers]

@POFerro This an intentional change in behavior. Most people don't like scaffolding of a nullable property here, so starting with EF8, we create a non-nullable property and then set things up so that the database always ends up with true if the property is true and false if the property is false.

The breaking change doc I referenced shows how you can go back to the old behavior if needed.

[POFerro]

Hi @ajcvickers ,

I understand this is the new behavior and welcome it :). The issue is that if I don't fill any value on the bool property it gets written as false to the database thus ignoring the default value.
As written in the doc you sent:
"If the database has a default value of true for the column, then even though the value of the property is false, the value in the database ends up as true."->This is not happening, the value is being sent false to the database.

Can you please check if I misunderstood anything?

Best regards
POFerro

Please check the very simple sample I send attached.

[ajcvickers]

@POFerro Sorry, I misspoke earlier. If the default is true, and the property value is true, then no value will be sent to the database when the value on the CLR type is true, which means the end result is true. If the default is true, and the property value is false, then false will be sent to the database, and the result in the database is false. This means that the value in the database is true if and only if the property value is true, and false if and only if the property value is false.

The reason we have this logic is that for non-nullable bools, there can only be one of two values on the property, and there can only be one of two values in the column. It makes sense that the value in the entity is the same value that ends up in the database. A property that results in true in the database regardless of whether the value is true or false on the entity type is not useful. If you really need to distinguish not set from true/false, then you need to use a nullable bool.

[POFerro]

Hi @ajcvickers ,

What I understand is that the actual behavior is different than the one described in the "Why" section of the breaking changes docs, is that correct? Basically when in docs is said:

If the database has a default value of true for the column, then even though the value of the property is false, the value in the database ends up as true

and

A bool property will not have its value sent to the database if that value is false, which is the CLR default

These statements in the breaking changes documentation are not correct?
When you say:

If the default is true, and the property value is false, then false will be sent to the database, and the result in the database is false

This is what happens whenever I create a new object in C# (bool props not null have false values) and so I can never truly use the default value of the database.

What I inferred from the "Why" paragraph is that the decision was made by inspecting the state of the property ( unchanged on Add was not sent to the DB and so it would allow to have the default db value be filled ).

If the implementation is like what you described in your comments than please update the docs so it becomes clearer that every bool with a default value in the database have to be explicitly set to true in code so that the value gets inserted as true in the database ( this also means that the default value for the database is in fact useless when used in EF ).

Please correct any of my statements if I am misinterpreting anything.

Best regards
POFerro

[ajcvickers]

If the database has a default value of true for the column, then even though the value of the property is false, the value in the database ends up as true

This is describing the old behavior. I will update the breaking change documentation to make it more clear.

If the implementation is like what you described in your comments than please update the docs so it becomes clearer that every bool with a default value in the database have to be explicitly set to true in code so that the value gets inserted as true in the database ( this also means that the default value for the database is in fact useless when used in EF ).

Yes, this is true. There are two possible values for the bool property--true or false. If the property value is true, then the database value will be true. If the property value is false, then the database value will be false. The only other options are:

• The value is always true in the database, regardless of what the value of the property is.
• The value is always false in the database, regardless of what the value of the property is.
• The value is false in the database when the property value is true, and the value in the database is true when the property value is false.

Which of these behaviors are you looking for?