Including read-only columns in an Entity Framework model

Question

Suppose I have a .NET Entity Framework model class:

public class Foo
{
    public int FooId { get; set; }

    public string Description { get; set; }

    public DateTime Created { get; set; }

    public DateTime LastUpdated { get; set; }
}

The Created and LastUpdated columns in my SQL Server table, both of type DATETIME2, have a DEFAULT constraint (SYSUTCDATETIME()). An AFTER UPDATE trigger sets LastUpdated to SYSUTCDATETIME whenever the Description is changed.

In my code, when I'm reading from the Foo table, I want Created and LastUpdated included, because I want to use their values. But when I'm adding a row to the table, I don't want them included in the Add because I want SQL Server to use the default value I've configured it to use. I thought it would just have been a matter of having

Foo foo = new Foo
{
    Description = "This is my latest foo."
}

but C# is giving the two date properties their own default value of 0001-01-01T00:00:00.000000, which isn't null, and this is what's getting recorded in the table.

Isn't there an attribute that tells the framework not to write a property back to the database? It isn't NotMapped because that would prevent the values from being read.

Consider closing the question. Default / read-only values and the behavior of `Computed` vs. `Identity` columns have been covered a few times in StackOverflow such as: https://stackoverflow.com/questions/18506088/entityframework-not-updating-column-with-default-value — Steve Py, Jan 26 '21 at 22:22
@StevePy I would have closed it, but the site doesn't allow self-closure for two days after posting. — Green Grasso Holm, Jan 27 '21 at 00:39

score 0 · Accepted Answer · answered Jan 26 '21 at 21:46

`Don't you hate when you find the answer right after posting your question?

[DatabaseGenerated(DatabaseGeneratedOption.Computed)] omits the property from inserts and updates.
[DatabaseGenerated(DatabaseGeneratedOption.Identity)] omits the property from inserts.

The latter will take care of EndDate, which I didn't illustrate in my post. I have the database set a default value of 9999-12-31T23:59:59 on insert, but my application will change its value later when Foo is meant to expire.

What kills me is they based the naming on specific use cases that wouldn't come to mind in a different scenario. They ought to have gone with [SkipOnInsert] and [SkipOnUpdate] (which could then be combined as needed).

Including read-only columns in an Entity Framework model

1 Answers1