This ended up working for me, Entity Framework 5.
- Turn off automatic migrations
- Migrate to create the initial table, no frills
-
Declare the
ClusterIdas Identity (annotation)[DatabaseGenerated(DatabaseGeneratedOption.Identity)] public override int ClusterId { get; set; } -
Migrate
-
Declare the pk property
Idas Identity after the other one has been updated[DatabaseGenerated(DatabaseGeneratedOption.Identity)] public override Guid Id { get; set; }- bonus: EF seems to assume
Idis primary key, so you don’t need[Key, Required]
- bonus: EF seems to assume
-
Create the migration code like
add-migration TrickEfIntoAutogeneratingMultipleColumns - In the
Up()method, in theAlterColumnstatement, tell the database to autogenerate the GUID by declaring thedefaultSqlValueAlterColumn(theTable, "Id", c => c.Guid(nullable: false, identity: true, defaultValueSql: "newid()"));
- Migrate
This seems to “trick” EF, in the sense that it assumes both columns are identities and reacts accordingly. During migration, it tries to make another column an identity, but seemingly doesn’t care when that silently fails — you end up with one marked as Identity and the other with a default value.
During normal code operation, when EF goes through the SaveChanges/ChangeTracking steps, because it sees the Id property as an Identity it does it’s whole “assign temporary key” thing, so that it’s not trying to use the default 0000000… value, and instead lets the database generate it using the default value function you specified.
(I would have thought annotating this field as Computed would have accomplished the same thing, but…the errors I mentioned in the question…boo…)
And, because the ClusterId field is also an Identity in code, and really is an Identity in the database, it autoincrements as well.