2

I'm upgrading from EF Core 2.2 to EF Core 3.1. I have an entity Patient with a GUID Id:

class Patient { 
   public Guid Id { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
}

A DbSet is defined for this type:

public DbSet<Patient> Patients { get; set; }

In EF 2.2, when I added a new Patient, the Id would be automatically generated when the object was added to the DbSet:

// newPatient.Id -> 00000000-0000-0000-0000-000000000000
ctx.Patients.Add(newPatient);
// newPatient.Id -> C1D5ACB8-A4C9-4680-AF2F-BF5E5B0AC1B6     <=== GUID generated

Now, in EF 3.1, the Id is not being automatically generated upon Add:

// newPatient.Id -> 00000000-0000-0000-0000-000000000000
ctx.Patients.Add(newPatient);
// newPatient.Id -> 00000000-0000-0000-0000-000000000000     <=== still an empty GUID

This obviously breaks my code.

In EF Core 3.0 there is a breaking change "String and byte array keys are not client-generated by default". However, this breaking change indicates string and byte array keys, not GUID keys. Also, I have tried the recommended mitigations with FluentAPI and Data Annotations and it does not resolve my issue (still no GUID generated).

I am using the dotConnect for Oracle database provider v9.11. I did not find any breaking changes there that would affect this.

Of course I can explicitly assign a GUID Id in my code, but I'd like to make this work as it did before in EF Core 2.2.

Any suggestions why this is not working? Thanks.

realmikep
  • 593
  • 1
  • 6
  • 22
  • 1
    Probably the same reason as for https://stackoverflow.com/questions/58147041/changes-in-identity-column-after-ef-core-3/58147159#58147159, i.e. breaking change [Temporary key values are no longer set onto entity instances](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.0/breaking-changes#temporary-key-values-are-no-longer-set-onto-entity-instances) – Ivan Stoev Apr 09 '20 at 11:21
  • @IvanStoev good find, I hadn't see that post. I saw that breaking change but I didn't think it fit because the Guid was always the permanent key, however that's probably because it's a Guid and not an autogenerated ID. – realmikep Apr 09 '20 at 15:59
  • It probably depends on the provider. For SqlServer by default the generated Guids are permanent and are set onto entity. But when configured with `HasDefaultValueSql("newid()")` the generated Guids are temporary and are not set onto entity. – Ivan Stoev Apr 09 '20 at 16:08

0 Answers0