SaveChanges fails for owned entity when owner has PK with default values

[smitpatel]

    public class Blog
    {
        public int Id1 { get; set; }
        public int Id2 { get; set; }
        public OwnedType Type { get; set; }
    }

    [Owned]
    public class OwnedType
    {
        public string Value { get; set; }
    }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            // Configure model
            modelBuilder.Entity<Blog>().HasKey(e => new { e.Id1, e.Id2 });
        }

                db.Add(new Blog { Type = new OwnedType { Value = "A" } });

                db.SaveChanges();

Adding only Blog works fine. Adding owned type with blog throws error

An exception occurred in the database while saving changes for context type 'EFSampleApp.MyContext'.
      System.InvalidOperationException: The value of 'OwnedType.BlogId1' is unknown when attempting to save changes. This is because the property is also part of a foreign key for which the principal entity in the relationship is not known.
         at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntry.PrepareToSave()
         at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.GetEntriesToSave(Boolean cascadeChanges)
         at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(DbContext _, Boolean acceptAllChangesOnSuccess)
         at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerExecutionStrategy.Execute[TState,TResult](TState state, Func`3 operation, Func`3 verifySucceeded)
         at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChaUnhandled exception.nges(Boolean acceptAllChangesOnSuccess)
         at Microsoft.EntityFrameworkCore.DbContext.SaveChanges(Boolean acceptAllChangesOnSuccess)
      System.InvalidOperationException: The value of 'OwnedType.BlogId1' is unknown when attempting to save changes . This is because the property is also part of a foreign key for which the principal entity in the relationship is not known.
         at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntry.PrepareToSave()
         at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.GetEntriesToSave(Boolean cascadeChanges)
         at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(DbContext _, Boolean acceptAllChangesOnSuccess)
         at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerExecutionStrategy.Execute[TState,TResult](TState state, Func`3 operation, Func`3 verifySucceeded)
         at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(Boolean acceptAllChangesOnSuccess)
         at Microsoft.EntityFrameworkCore.DbContext.SaveChanges(Boolean acceptAllChangesOnSuccess)

Happens for SqlServer/InMemory (provider agnostic.

[ajcvickers]

@smitpatel Regression?

[smitpatel]

Did not try on older release. Ran into this when writing test in main branch.

[ajcvickers]

Confirmed regression from 3.1.

[ajcvickers]

Marking for re-triage. This only happens when the key value is not configured as generated, but no key value is set. This is a pseudo-negative case. That is, the first entity saved like this in 3.1 would have succeeded because the key value of zero is not taken yet. The second entity saved will cause a primary key violation.

We should still look at either making this work for the first case, or more likely throw a better exception. But I don't think we need to patch.

[tosatoandrea]

I ran into this problem when I try to add and save an entity with self relation

[ajcvickers]

@tosatoandrea and others who have thumbs-uped this issue. Are you sure you are running into this problem and not something different that generates the same error message? This particular issue only happens when you try to save entities that are configured not to have store-generated keys and yet do not have a key value set. This exception happens the first time you do this, but even if we fix this exception you will still get an error on the next entity saved, since it will have a conflicting key value.

Therefore, it doesn't seem like fixing this will enable any meaningful scenarios. If you are hitting this, then can you explain what the scenario is so that we can better understand the value of making the fix?

[ajcvickers]

Note from triage: fix in 6.0 for now; hold off on patching until we get a confirmed customer report that isn't doing something that will always fail later.

[CampaginAgent]

@ajcvickers - I think I've hit up against this bug in a real-world case that that won't always fail later.

I'm converting a 3.1 to 5.0 application. This was working perfectly under 3.1 for a long time.

I have a value object defined as:

public class VpaApplicationAgreementSection : ValueObject
   {
       public enum AgreementSectionType
       {
          CoverPage,
          TermsAndConditions,
          Deed,
         ActionLogs
       }

       public AgreementSectionType Type { get; protected set; }
       public string Label { get; protected set; }

       /// <summary>
       /// A Zero-based index 
       /// </summary>
       public int DocumentIndex { get; protected set; }

       public AgreementVersion AgreementVersion { get; protected set; }
   }

This value object is part of an owns-many relationship, defined as

builder.OwnsMany(x => x.AgreementSections,
                           cb =>
                           {
                               cb.ToTable("VpaApplicationAgreementSections", "VpaApply");
                               cb.WithOwner().HasForeignKey("VpaApplicationId");
                               cb.Property(p => p.Type).HasConversion<string>().HasColumnName("Type");
                               cb.Property(p => p.Label).HasColumnName("Label");
                               cb.Property(p => p.DocumentIndex).HasColumnName("DocumentIndex");
                               cb.OwnsOne(x => x.AgreementVersion,
                                          ccb =>
                                          {
                                              ccb.Property(p => p.MergeTemplateAggregateId).HasColumnName("MergeTemplateAggregateId");
                                              ccb.Property(p => p.Version).HasColumnName("Version");
                                          });
                               cb.UsePropertyAccessMode(PropertyAccessMode.Field);
                               cb.HasKey("VpaApplicationId",
                                        "Type", 
                                         "Label",
                                         "DocumentIndex"
                                         
                                         );
                           });

Upon migration of EF5, some of our tests fail with:
System.InvalidOperationException: The value of 'VpaApplicationAgreementSection.AgreementVersion#AgreementVersion.VpaApplicationAgreementSectionType' is unknown when attempting to save changes. This is because the property is also part of a foreign key for which the principal entity in the relationship is not known.

In our value object, DocumentIndex = 0 and Type = AgreementSectionType.CoverPage are both valid values, however, because these also happen to coincide with the C# default values for the int and our enum, we hit up against this bug.

If I change my code so that DocumentIndex starts as one, and my enum is defined as:

        public enum AgreementSectionType
        {
           None,
            CoverPage,
           TermsAndConditions,
           Deed,
          ActionLogs
        }

then my test-suite passes. - This work-around feels a little distasteful, as 'None' is not really a valid value in my domain.

[SimonCropp]

given 5.0.4 is released , should this be closed?

[Sayan751]

Facing this in 5.0.9. Tried all the versions till 5.0.5. Faced the same issue in all versions. This seems not to be fixed. Please consider reopening this and fixing it in 5.x.

[ajcvickers]

@Sayan751 Please open a new issue and attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate.

[diev]

I have found this issue trying to solve a problem in 6.0.
I used Guid id = Guid.Empty; as the root Ids of my self referenced many-to-many relationship and I had same error.

My solution is to replace this with Guid id = Guid.Parse("00000000-0000-7000-0000-000000000000");. This works.