SQLite default column value overrides the passed value on initial create.

When saving an initial record into a SQLite table, the default column value overrides the passed in value.

DefaultTest.zip

Steps to reproduce

I have attached a small project that demonstrates the issue. I have left it as close as possible to my implementation just in case it’s something I’m doing.

Load the project in VS2015, restore dependencies, build and run the xUnit tests (1 passes and 1 fails).

Explanation of test project

In the test CarrierFacts.Carrier_List_Success the 3 entities are added to the database, this is actually where the failure emanates from as the 3rd entity (OOL) has the IsActive flag set to true. This can be checked in the CarrierBuilder.SetEditor method where you can check that the 3 entities do have their IsActive flags set correctly, then when SaveChanges is called on the DbConext, and the context table records are viewed, you can see the IsActive flag no longer matches.

Further technical details

EF Core version: 1.1.0 (found in project.json or packages.config) Database Provider: Microsoft.EntityFrameworkCore.Sqlite) Operating system: Windows 10 (64 bit) IDE: (e.g. Visual Studio 2015)

[bricelam]

EF Core uses the CLR default value to determine if it should use the SQL default.

With a bool property .HasDefaultValue(true) means:

.NET	SQL
false	1 (via DEFAULT)
true	1

With a bool? property:

.NET	SQL
null	1 (via DEFAULT)
false	0
true	1

It sounds like you don’t really want a DEFAULT constraint in the database. Maybe defaulting the CLR property is a more appropriate solution for your application.

[ensemblebd]

Occurs in .net 4.6.2 as well. Probably higher.

Not trying to necro, but jesus this is a bad one. SQL Default values override passed values of the model. That’s some crazy shit.

Only truly viable option is to create the record, then update it afterwards. Since EF6 makes invalid assumptions about how the database is meant to be operated. Thank god I’m using the Manager pattern, I can just override. I refuse to alter good database design and good code enforcement, in favor of whatever the hell logistics this is meant to be.

Who in their right mind would make a non-nullable column with a default value (so as to enforce strict model usage with proper values passed), and then entirely ignore INSERT values in favor of whatever default the sql db has. That’s next level dude. Next. Level.

Took a long time to find this. Still a problem in 2019. But after all the other issues I’ve encountered, I’m not surprised. EF is meant for dev’s who conform to EF, not for database admins who want to make their life easier and ensure their employees stay true to proper code. That should be a massive surgeon general warning label. More like tear your hair out and stuff it in your face after spending 6 hours debugging, then pollute your code with workarounds.

To say I’m angry, is an understatement. Good job Microsoft. 0/10 on usability for this one. And love seeing how you close the ticket in favor of not solving the problem - 10/10 classic.