Change tracking throws InvalidCastException when enum is bound to tinyint in Sqlite

[ArrowCase]

Versions

Windows 10
Visual Studio 16.2 Preview 1
.NET Core SDK 3.0.100-preview6-012264
NETCore.App 3.0.0-preview6-27804-01
Microsoft.EntityFrameworkCore.Sqlite 3.0.0-preview6.19304.10

Steps to reproduce

• Create a project using EF Core with Sqlite.
• Create an entity class with an enum property whose base type is anything other than long.
• Use annotations or fluent calls to configure the enum to use a tinyint column.
• Create a DbContext with that entity.
• Add a new entity and call SaveChanges().

Full repro gist here.

Note: this bug reproduces if the base type of the enum is explicitly set to something other than long, or if it is left as the implicit default of int.

Expected result

The record is created with no errors.

Actual result:

The database is created successfully with a tinyint (INTEGER affinity) data type, but attempting to save changes after adding the entity fails:

System.InvalidCastException: 'Unable to cast object of type 'EnumRepro.State' to type 'System.Int64'.'
   at Microsoft.EntityFrameworkCore.ChangeTracking.ValueComparer`1.Equals(Object left, Object right)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.ChangeDetector.LocalDetectChanges(InternalEntityEntry entry)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.ChangeDetector.DetectChanges(IStateManager stateManager)
   at Microsoft.EntityFrameworkCore.ChangeTracking.ChangeTracker.DetectChanges()
   at Microsoft.EntityFrameworkCore.DbContext.TryDetectChanges()
   at Microsoft.EntityFrameworkCore.DbContext.SaveChanges(Boolean acceptAllChangesOnSuccess)
   at Microsoft.EntityFrameworkCore.DbContext.SaveChanges()

It seems strange that change tracking needs to cast the enum to Int64 to compare it, but it's even stranger that the cast can somehow fail.

[ajcvickers]

@ArrowCase SQLite doesn't have a column type tinyint. SQLite will let you specify anything, but it doesn't mean anything unless it's one of the four types that it understands. Is there a reason you are specifying tinyint on SQLite?

Note for triage: this happens because when picking a value conversion we reject it if it would not result in the correct mapping for the type specified. But since in this case the type specified is never correct, we will never accept the conversion. I'm not sure there is a good way to deal with this, but maybe we can have one behavior for store types we know, and a different one for store types we don't know.

[ArrowCase]

@ajcvickers

Is there a reason you are specifying tinyint on SQLite?

My code was originally written for LocalDB, and I switched providers to Sqlite thinking I shouldn't have to worry about the column annotations since Sqlite understands those data types even though it doesn't actually use them. In this case, the enum column is created just fine with INTEGER affinity.

It seems like a bad experience that the tinyint annotation is acceptable for creating and reading from the column, but not for updating it, due to this issue in change tracking.

[ajcvickers]

@ArrowCase Thanks for the additional info.

Note from triage: we should discuss with @bricelam

[ajcvickers]

@bricelam to explain the difference between "supported types" and "type affinity".

[bricelam]

SQLite supports four types: INTEGER, REAL, TEXT & BLOB. It uses a type affinity to determine the preferred way the data for a column should be stored on disk. But it also supports dynamic typing, so if converting to that type affinity would result in data loss, it won't be used.

We use those same affinity rules here to determine a suitable CLR type when reverse engineering a model. (#8824 is about picking an even better CLR type by sampling the data)