Support modifying the value of primary or alternate key properties

[tuespetre]

In the following location, an exception is raised when attempting to make modifications to a property that belongs to either a primary or alternate key (using the IsKey extension method):

https://github.com/aspnet/EntityFramework/blob/7.0.0-rc1/src/EntityFramework.Core/ChangeTracking/Internal/InternalEntityEntry.cs#L231

I have to ask: why restrict modifications on alternate keys, and why not use IsPrimaryKey here instead?

[lundcm]

If you're intending on just making a field unique then you can just do this and updates can be made after the initial save. This would be in the DbContext.

    public class ApplicationDbContext : DbContext
    {
        public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { }

        protected override void OnModelCreating(ModelBuilder builder)
        {
            base.OnModelCreating(builder);

            builder.Entity<ModelName>()
                .HasIndex(b => b.FieldName)
                .IsUnique();
        }
    }

[divega]

Keywords: mutable alternate keys.

[divega]

We discussed mutability of alternate keys once more in the context of #8645. There is a continuum of scenarios we could enable:

1. If they do not act as the principal side of any relationships they can be mutable
2. Else if they are principal but a specific instance does not have any dependency they can be mutated (we would fail if they have dependent in memory and let the database fail if there are dependents that were not loaded in memory)
3. Allow for them to be mutated even when they have dependents. This is more challenging but we believe it can be done with the help of ON UPDATE CASCADE and or translating the UPDATE operation to a sequence of INSERT new principal, UPDATE dependent foreign keys, DELETE all principal.

[ajcvickers]

See also the scenario in #14210

[mguinness]

I just bumped into this, is there a way to update a field used in an alternate key (introduced with HasPrincipalKey) other than using ADO.NET? I'm using email as a natural key, see #14210 (comment). I was hoping that by specifying DeleteBehavior.Restrict it would permit this.

[SidShetye]

Upvoted to resolve this limitation.

We're also running into this issue where the underlying database is shared across multiple apps and we're have to work with that db in EF Core 3.0. We're getting the exception shown below (laced with dba jargon than developer friendly english!). Especially strange because the alternate key isn't used as a foreign key by any other entity (or principal). The alternate key in that database (we share) is being used only for uniqueness, a fairly normal thing to do.

System.InvalidOperationException: The property 'SomePropertyName' on entity type 'SomeEntity' is part of a key and so cannot be modified or marked as modified. To change the principal of an existing entity with an identifying foreign key first delete the dependent and invoke 'SaveChanges' then associate the dependent with the new principal.

[AndriySvyryd]

@SidShetye If you only need uniqueness use a unique index instead of an AK

[SidShetye]

@AndriySvyryd Like I mentioned, we share that database (don't control the schema; not using migrations etc). We're just trying to regenerate it's closest approximation in the C# EF Core 3.0 model. Not having that limitation would allow for a more accurate approximation of the actual SQL database in EF Core.

[AndriySvyryd]

@SidShetye Configuring it as a unique index in EF would be the most accurate approximation. If you don't use EF to manage the schema you don't even need to add the index, EF doesn't use it.

If you do use migrations you can change the generated code to create a key instead.

[SidShetye]

If you don't use EF to manage the schema you don't even need to add the index, EF doesn't use it.

@AndriySvyryd, that's the key confirmation, thanks. So no major side effects of skipping the AK present in the DB. That actually works for us.

[keatkeat87]

I m trying to use sql server cascade update to doing this. but sometime it will facing the cascade multiple path problem.
for cascade delete normally we just need a trigger instead.
but cascade update is not so easy, we need to first disable nocheck constraint then update all the child after than only can update the main and then enable constraint again.
just sharing my experience here.

[luy710]

disable nocheck constraint
how to disable nocheck constraint

[Jeffery-Glenn]

I also would like to express my support for this as we have a system that uses this and dropping to raw .net / TSQL is not a very clean way to work around it.