In Entity Framework 6 it's just the way it is. When uniqueidentifier
columns are primary key and have a default value, the EDMX generator tool doesn't mark them as DatabaseGeneratedOption.Identity
. In a strict sense that's right, because the column doesn't have (can't have) an identity specification.
So in the EDMX designer you have to set the StoreGeneratedPattern
property of the Id column(s) to Identity
manually. The good new is that this survives model updates.
The net effect for EF is similar to a true (= numeric) identity column. Whether or not an explicit value is assigned to the Id column:
- The column is ignored in
INSERT
statements
- The generated value is read into the entity during
SaveChanges
.
As indicated by your comment, Entity Framework-core (current version 2.0.0) handles this differently. When a model is generated from a database (package manager console: Scaffold-DbContext
), you'll see an entry in the context's OnModelCreating
override looking like this:
entity.Property(e => e.Id)
.HasColumnName("ID")
.HasDefaultValueSql("(newsequentialid())");
But the behavior is subtly different than in EF6. When no value is set for the Id column (i.e. it is a default Guid
) the behavior is still the same:
- The column is ignored in the
INSERT
statement
- The generated value is read into the entity during
SaveChanges
.
However, when the Id
column is set to another value than the default:
- The column is part of the
INSERT
statement
- There is no generated value.
That means that, other than in EF6, as a developer you have to take care that no explicit values are assigned to Guid
PK properties if you want them to be always generated by the database.