Mapping unsupported uint in a new db provider (

[ronnyek]

Greetings... as a disclaimer I struggled whether this should be where I ask this question or stackoverflow. Decided to ask here as the audience is possibly more likely to hit people working on actual providers, not the consumers of those providers.

I'm experimenting building a provider for a database engine that currently has no entity framework core driver. Modeling this driver off source I've found for sqlite and mssql providers, I've actually gotten quite far, but running into a problem.

Northwind tests are mostly passing, but this db provider does not support uint (and Employee and a few other fields are designed to have unit32 fields. I've tried providing an explicit typemapping for uint32 to try to just use bigint at the database level. I've also tried omitting the mapping (following the mssql implementation) and things actually work remarkably well. I can query objects and have it return the uint as int.

Right now queries are working (with no explicit type mapping for uint), but then as a part of this base test, there is an explicit call to change detector to detect changes. As soon as it does this, the ValueComparer in the change detector blows up as its trying to convert System.UInt32 to System.Int32

I'm just struggling to understand what would be the best way to handle this. Basically when efcore sees a property of this type of primitive on an object, treat it in the db as another type.

#16111 seems to be a related question, but the fixes are things that I believe already exist in this code.

I'd also like to know why mssql provider seems to make comments about mssql not supporting unsigned types, but appears to run those same tests, and presumably those tests pass.

Appreciate any pointers anyone can give. I just want to make sure this efcore provider is as "correct" as it can be, and passing as many tests as possible.

Currently targeting efcore 6, but not specifically tied to that version...

[ajcvickers]

@ronnyek Your type mapping source should return type mappings for all types that are natively supported by the underlying database. If your type mapping source does not return a mapping for a given type, then EF will attempt to find a type that is mapped by the database to which the unmapped type can be converted. The provider doesn't need to do anything for this to work. So, for example, SQL Server does not have a native mapping for uint. This means it's type mapping source returns null when asked for such a mapping. EF then automatically uses the uint to long converter and saves uints to the database as longs--so as far as the provider is concerned, the type it sees is long, not uint.

[ronnyek]

@ajcvickers I think that simple explanation of what mapping source should do was exactly the trick. I removed mappings I had created that were unnecessary, and made sure my fixture wasnt trying to explicitly set column types, and that test now passes.

I appreciate you taking the time to answer... now I just have to work through some other type mapping issues... but at least I have a far better idea of what is SUPPOSED to be happening here.

[ronnyek]

In that northwind model, EmployeeID is setup as a uint, storing internally as nullable uint.

If I have no explicit mappings for nullable uint or uint, I'd assume EFCORE should handle that right? I've managed to get efcore handling the EmployeeID field but now running into the exact same problem with ReportsTo on the Employee type which is setup as a uint?

[ronnyek]

I'm sorry, 2 seconds after hitting save, I realized there was an explicit .HasColumnType setup for the fixture overrides. Removing that, and things are passing for ReportsTo as well.