You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello. I'm testing the use of C# 9 records as models for EF and I've confirmed that, albeit being immutable, the record object passed to .Add() gets its autogenerated ID field updated after .SaveChanges().
I think that this behaviour is intentional (and very convenient, of course), but as it clashes directly with the immutability of records, I want to ask if I can rely on this behaviour for future developments. I'm unable to find anything about it on the available documentation.
Regards.
The text was updated successfully, but these errors were encountered:
EF doesn't currently have a full story for truly immutable CLR types; such a full story would mean eventually refraining from updating the immutable entity with the database-generated ID. Instead, a new instance would be created and returned with the new ID. However, if the current behavior is what you want, that should be fine - we'll very likely always allow you to e.g. have a private writable field, where EF would inject the ID. This way, although the type technically isn't fully immutable, it doesn't publicly expose APIs for mutation.
Hello. I'm testing the use of C# 9 records as models for EF and I've confirmed that, albeit being immutable, the record object passed to
.Add()
gets its autogenerated ID field updated after.SaveChanges()
.I think that this behaviour is intentional (and very convenient, of course), but as it clashes directly with the immutability of records, I want to ask if I can rely on this behaviour for future developments. I'm unable to find anything about it on the available documentation.
Regards.
The text was updated successfully, but these errors were encountered: