DatabaseGeneratedOption: Identity vs. Computed

Question

I am trying to understand the (functional) difference between the two DatabaseGeneratedOption's in Entity Framework (code first):

• DatabaseGeneratedOption.Identity
• DatebaseGeneratedOption.Computed

I have read the documentation, but I do not understand the functional difference between the two.

The option Identity is described as The database generates a value when a row is inserted. But I cannot update the value later if I try I get an exception saying that I cannot modify a column with Identity pattern.

The option Computed is described as The database generates a value when a row is inserted or updated. However, this is just what you tell Entity Framework, so far I have not been able to achieve this, without SQL triggers. If I try to update the value, nothing happens (Entity Framework refuses to overwrite the existing value).

So what I am left with, is two functionally identical options. I can have a default value in my SQL table, which will be applied on the insert. And I cannot update this value afterward (using Entity Framework). So where in lies the difference in how they should be used?

Answer 1

A computed column contains a value that is computed (hence the name) when the record is requested.

A computed column can be composed of other column values, constants and function return values.

You could for example create a computed column for an invoice expiry date:

CREATE TABLE Invoice
(
    InvoiceDate DATETIME NOT NULL,
    ExpiryDate AS DATEADD(DAY, 30, InvoiceDate)
)

Now if you mark this column as computed in Entity Framework, it will refuse any updates to that column, because it'll know the database won't support that.

So the documentation for that attribute is incorrect or incomplete.

A column marked as Identity will use the database-specific syntax to generate a primary key for the given table when inserting a record, being IDENTITY() in MSSQL and AUTO_INCREMENT for MySQL. A computed column will simply be marked as read-only, and you'll have to provide your own implementation (either in the database or in your migration file) to specify the computation (see How to add computed column using migrations in code first?).