Getting Entity Framework to set LONGs to zero instead of requiring a nullable property

Question

We have a database-first Entity Framework 6.1.3 project that is serializing to a Java-based caching product (in addition to normal SQL Server persistence). As a result, none of the domain classes in the project can have nullable LONGs. They aren't compatible with GemFire. Only normal LONGs can be used.

But we do have NULLs in our underlying SQL Server database (in its BIGINT columns). Normally this would just be handled by adding a question mark to the property:

public long? SomeProperty { get; set; }

In our case, we need a way to make Entity Framework live without the question mark. The property needs to be a straight LONG; Entity Framework should set it to zero if the underlying row has a NULL. Maybe the EF fluent API provides a way to do this? I'm picturing something like this:

Property(t => t.SomeProperty).HasColumnName("SomeProperty").IsOptional();

Needless to say, that does not work (as written, anyway). I still get the following exception:

The 'SomeProperty' property on 'MyDomainClass' could not be set to a 'null' value. You must set this property to a non-null value of type 'System.Int64'.

Does someone know of a way to get EF to tolerate NULLs in a BIGINT column without marking the property as nullable in C#?

Answer 1

One practical approach is, instead of the table, create a view feeding from the original table having "not null" fields:

CREATE VIEW MY_TABLE_VIEW
AS
   ...
   ISNULL(SOME_PROPERTY, 0) AS SOME_PROPERTY
   ...

Since the project's/environment's limitations are unknown, it is hard to surely tell if it will work for you.