Nie można zmienić relacji, ponieważ co najmniej jedna właściwość klucza obcego nie ma wartości zerowej

Dostaję ten błąd, gdy wykonuję GetById () na encji, a następnie ustawiam kolekcję encji potomnych na mojej nowej liście, która pochodzi z widoku MVC.

Operacja nie powiodła się: Nie można zmienić relacji, ponieważ co najmniej jedna właściwość klucza obcego nie ma wartości zerowej. Po zmianie relacji powiązana właściwość klucza obcego jest ustawiana na wartość zerową. Jeśli klucz obcy nie obsługuje wartości pustych, należy zdefiniować nową relację, właściwość klucza obcego musi mieć przypisaną inną wartość inną niż pusta lub niepowiązany obiekt musi zostać usunięty.

Nie do końca rozumiem tę linię:

Nie można zmienić relacji, ponieważ co najmniej jedna właściwość klucza obcego nie ma wartości zerowej.

Dlaczego miałbym zmieniać relacje między 2 podmiotami? Powinien pozostać taki sam przez cały okres istnienia całej aplikacji.

Kod, na którym występuje wyjątek, polega na prostym przypisaniu zmodyfikowanych klas potomnych w kolekcji do istniejącej klasy macierzystej. Mam nadzieję, że przyczyni się to do usunięcia klas podrzędnych, dodania nowych i modyfikacji. Myślałem, że Entity Framework to załatwi.

Wiersze kodu można przedestylować do:

var thisParent = _repo.GetById(1);
thisParent.ChildItems = modifiedParent.ChildItems();
_repo.Save();

Stare elementy potomne należy usuwać thisParent.ChildItemsręcznie jeden po drugim. Entity Framework tego nie robi. W końcu nie może zdecydować, co chcesz zrobić ze starymi elementami potomnymi - jeśli chcesz je wyrzucić lub jeśli chcesz zachować i przypisać je innym podmiotom nadrzędnym. Musisz poinformować Entity Framework o swojej decyzji. Ale jedną z tych dwóch decyzji musisz podjąć, ponieważ podmioty potomne nie mogą żyć same bez odniesienia do jakiegokolwiek rodzica w bazie danych (z powodu ograniczenia klucza obcego). Tak w zasadzie mówi wyjątek.

Edytować

Co zrobiłbym, gdyby elementy potomne można było dodawać, aktualizować i usuwać:

public void UpdateEntity(ParentItem parent)
{
    // Load original parent including the child item collection
    var originalParent = _dbContext.ParentItems
        .Where(p => p.ID == parent.ID)
        .Include(p => p.ChildItems)
        .SingleOrDefault();
    // We assume that the parent is still in the DB and don't check for null

    // Update scalar properties of parent,
    // can be omitted if we don't expect changes of the scalar properties
    var parentEntry = _dbContext.Entry(originalParent);
    parentEntry.CurrentValues.SetValues(parent);

    foreach (var childItem in parent.ChildItems)
    {
        var originalChildItem = originalParent.ChildItems
            .Where(c => c.ID == childItem.ID && c.ID != 0)
            .SingleOrDefault();
        // Is original child item with same ID in DB?
        if (originalChildItem != null)
        {
            // Yes -> Update scalar properties of child item
            var childEntry = _dbContext.Entry(originalChildItem);
            childEntry.CurrentValues.SetValues(childItem);
        }
        else
        {
            // No -> It's a new child item -> Insert
            childItem.ID = 0;
            originalParent.ChildItems.Add(childItem);
        }
    }

    // Don't consider the child items we have just added above.
    // (We need to make a copy of the list by using .ToList() because
    // _dbContext.ChildItems.Remove in this loop does not only delete
    // from the context but also from the child collection. Without making
    // the copy we would modify the collection we are just interating
    // through - which is forbidden and would lead to an exception.)
    foreach (var originalChildItem in
                 originalParent.ChildItems.Where(c => c.ID != 0).ToList())
    {
        // Are there child items in the DB which are NOT in the
        // new child item collection anymore?
        if (!parent.ChildItems.Any(c => c.ID == originalChildItem.ID))
            // Yes -> It's a deleted child item -> Delete
            _dbContext.ChildItems.Remove(originalChildItem);
    }

    _dbContext.SaveChanges();
}

Uwaga: To nie zostało przetestowane. Zakłada się, że kolekcja elementów potomnych jest typu ICollection. (Zwykle mam, ILista potem kod wygląda nieco inaczej.) Usunąłem też wszystkie abstrakty repozytoriów, aby było to proste.

Nie wiem, czy to dobre rozwiązanie, ale uważam, że należy wykonać jakąś ciężką pracę zgodnie z tymi wytycznymi, aby zająć się wszelkiego rodzaju zmianami w kolekcji nawigacji. Byłbym również szczęśliwy widząc łatwiejszy sposób na zrobienie tego.

Powodem tego jest różnica między kompozycją a agregacją .

W składzie obiekt podrzędny jest tworzony podczas tworzenia elementu nadrzędnego i jest niszczony, gdy element nadrzędny jest niszczony . Tak więc jego żywotność jest kontrolowana przez jego rodzica. np. post na blogu i jego komentarze. Jeśli post zostanie usunięty, jego komentarze powinny zostać usunięte. Komentarze do postu, który nie istnieje, nie ma sensu. To samo dotyczy zamówień i przedmiotów zamówienia.

W agregacji obiekt podrzędny może istnieć niezależnie od jego obiektu nadrzędnego . Jeśli element nadrzędny zostanie zniszczony, obiekt potomny może nadal istnieć, ponieważ można go później dodać do innego elementu nadrzędnego. np .: związek między listą odtwarzania a utworami na tej liście. Jeśli lista odtwarzania zostanie usunięta, utworów nie należy usuwać. Można je dodać do innej listy odtwarzania.

Sposób, w jaki Entity Framework różnicuje relacje agregacji i kompozycji, jest następujący:

• Do kompozycji: oczekuje, że obiekt potomny będzie miał złożony klucz podstawowy (ParentID, ChildID). Ma to na celu zaprojektowanie, ponieważ identyfikatory dzieci powinny należeć do ich rodziców.

• W celu agregacji: oczekuje, że właściwość klucza obcego w obiekcie potomnym będzie pusta.

Powodem tego problemu jest sposób ustawienia klucza podstawowego w tabeli podrzędnej. Powinien być złożony, ale nie jest. Tak więc Entity Framework traktuje to powiązanie jako agregację, co oznacza, że ​​po usunięciu lub wyczyszczeniu obiektów potomnych nie nastąpi usunięcie rekordów potomnych. Po prostu usunie to powiązanie i ustawi odpowiednią kolumnę klucza obcego na NULL (dzięki czemu te rekordy potomne mogą być później powiązane z innym rodzicem). Ponieważ twoja kolumna nie pozwala na NULL, otrzymujesz wspomniany wyjątek.

Rozwiązania:

1- Jeśli masz silny powód, dla którego nie chcesz używać klucza złożonego, musisz jawnie usunąć obiekty potomne. Można to zrobić prościej niż sugerowane wcześniej rozwiązania:

context.Children.RemoveRange(parent.Children);

2- W przeciwnym razie, ustawiając odpowiedni klucz podstawowy na tabeli podrzędnej, kod będzie wyglądał bardziej sensownie:

parent.Children.Clear();

To bardzo duży problem. To, co faktycznie dzieje się w twoim kodzie, to:

• Wczytujesz Parentz bazy danych i dostajesz dołączoną jednostkę
• Zastąpiłeś jego kolekcję potomną nową kolekcją dzieci odłączonych
• Zapisujesz zmiany, ale podczas tej operacji wszystkie dzieci są uważane za dodane, ponieważ EF nie wiedział o nich do tego czasu. Dlatego EF próbuje ustawić wartość null na klucz obcy starych dzieci i wstawić wszystkie nowe dzieci => zduplikowane wiersze.

Teraz rozwiązanie naprawdę zależy od tego, co chcesz zrobić i jak chcesz to zrobić?

Jeśli używasz ASP.NET MVC, możesz spróbować użyć UpdateModel lub TryUpdateModel .

Jeśli chcesz ręcznie zaktualizować istniejące dzieci, możesz po prostu zrobić coś takiego:

foreach (var child in modifiedParent.ChildItems)
{
    context.Childs.Attach(child); 
    context.Entry(child).State = EntityState.Modified;
}

context.SaveChanges();

Dołączanie nie jest tak naprawdę potrzebne (ustawienie stanu Modifiedspowoduje również dołączenie encji), ale podoba mi się, ponieważ sprawia, że ​​proces jest bardziej oczywisty.

Jeśli chcesz zmodyfikować istniejące, usuń istniejące i wstaw nowe dzieci, musisz zrobić coś takiego:

var parent = context.Parents.GetById(1); // Make sure that childs are loaded as well
foreach(var child in modifiedParent.ChildItems)
{
    var attachedChild = FindChild(parent, child.Id);
    if (attachedChild != null)
    {
        // Existing child - apply new values
        context.Entry(attachedChild).CurrentValues.SetValues(child);
    }
    else
    {
        // New child
        // Don't insert original object. It will attach whole detached graph
        parent.ChildItems.Add(child.Clone());
    }
}

// Now you must delete all entities present in parent.ChildItems but missing
// in modifiedParent.ChildItems
// ToList should make copy of the collection because we can't modify collection
// iterated by foreach
foreach(var child in parent.ChildItems.ToList())
{
    var detachedChild = FindChild(modifiedParent, child.Id);
    if (detachedChild == null)
    {
        parent.ChildItems.Remove(child);
        context.Childs.Remove(child); 
    }
}

context.SaveChanges();

Uważam, że ta odpowiedź jest znacznie bardziej pomocna w przypadku tego samego błędu. Wygląda na to, że EF nie lubi go po usunięciu, woli usunąć.

Możesz usunąć zbiór rekordów dołączonych do takiego rekordu.

order.OrderDetails.ToList().ForEach(s => db.Entry(s).State = EntityState.Deleted);

W tym przykładzie wszystkie rekordy szczegółów dołączone do zamówienia mają stan ustawiony na Usuń. (W przygotowaniu do dodania ponownie zaktualizowanych szczegółów, w ramach aktualizacji zamówienia)

Nie mam pojęcia, dlaczego pozostałe dwie odpowiedzi są tak popularne!

Uważam, że miałeś rację, zakładając, że struktura ORM powinna sobie z tym poradzić - w końcu to właśnie obiecuje. W przeciwnym razie Twój model domeny zostanie uszkodzony przez problemy związane z trwałością. NHibernate radzi sobie z tym szczęśliwie, jeśli poprawnie skonfigurujesz ustawienia kaskady. W Entity Framework jest to również możliwe, po prostu oczekują, że będziesz przestrzegać lepszych standardów podczas konfigurowania modelu bazy danych, szczególnie gdy będą musieli wywnioskować, jakie kaskady należy wykonać:

Musisz poprawnie zdefiniować relację rodzic-dziecko , używając „ relacji identyfikującej ”.

Jeśli to zrobisz, Entity Framework wie, że obiekt podrzędny jest identyfikowany przez obiekt nadrzędny, a zatem musi to być sytuacja „kaskadowo-usuń-sieroty”.

Inne niż powyższe, może być konieczne (z doświadczenia NHibernate)

thisParent.ChildItems.Clear();
thisParent.ChildItems.AddRange(modifiedParent.ChildItems);

zamiast całkowicie zastępować listę.

AKTUALIZACJA

Komentarz Slaumy przypomniał mi, że odłączone byty to kolejna część ogólnego problemu. Aby rozwiązać ten problem, możesz przyjąć podejście polegające na użyciu niestandardowego spoiwa modelu, który konstruuje modele, próbując załadować go z kontekstu. Ten post na blogu pokazuje przykład tego, co mam na myśli.

Jeśli używasz AutoMapper z Entity Framework na tej samej klasie, możesz napotkać ten problem. Na przykład, jeśli twoja klasa jest

class A
{
    public ClassB ClassB { get; set; }
    public int ClassBId { get; set; }
}

AutoMapper.Map<A, A>(input, destination);

Spróbuje to skopiować obie właściwości. W takim przypadku ClassBId nie ma wartości Nullable. Ponieważ AutoMapper skopiuje destination.ClassB = input.ClassB;, spowoduje to problem.

Ustaw AutoMapper na Ignoruj ClassBwłaściwość.

 cfg.CreateMap<A, A>()
     .ForMember(m => m.ClassB, opt => opt.Ignore()); // We use the ClassBId

Właśnie miałem ten sam błąd. Mam dwie tabele z rodzicielską relacją potomną, ale skonfigurowałem „kaskadę usuwania” w kolumnie klucza obcego w definicji tabeli potomnej. Kiedy więc ręcznie usunę wiersz macierzysty (przez SQL) w bazie danych, automatycznie usunie on wiersze potomne.

Jednak nie działało to w EF, pojawił się błąd opisany w tym wątku. Powodem tego było to, że w moim modelu danych encji (plik edmx) właściwości powiązania między tabelą nadrzędną i tabelą podrzędną były nieprawidłowe. End1 OnDeleteOpcja została skonfigurowana, aby być none( „koniec 1” w moim modelu jest koniec, który ma wiele 1).

Ręcznie zmieniłem End1 OnDeleteopcję na Cascadei wtedy zadziałało. Nie wiem, dlaczego EF nie jest w stanie tego podnieść, kiedy aktualizuję model z bazy danych (mam pierwszy model bazy danych).

Dla kompletności, tak wygląda mój kod do usunięcia:

   public void Delete(int id)
    {
        MyType myObject = _context.MyTypes.Find(id);

        _context.MyTypes.Remove(myObject);
        _context.SaveChanges(); 
   }    

Gdybym nie zdefiniował kasowania kaskadowego, musiałbym ręcznie usunąć wiersze podrzędne przed usunięciem wiersza nadrzędnego.

Dzieje się tak, ponieważ element podrzędny jest oznaczony jako Zmodyfikowany zamiast Usunięte.

A modyfikacja, którą EF robi dla elementu potomnego, gdy parent.Remove(child)jest wykonywana, polega po prostu na ustawieniu odwołania na jego element nadrzędny na null.

Możesz sprawdzić EntityState dziecka, wpisując następujący kod w oknie natychmiastowym Visual Studio, gdy wystąpi wyjątek, po wykonaniu SaveChanges():

_context.ObjectStateManager.GetObjectStateEntries(System.Data.EntityState.Modified).ElementAt(X).Entity

gdzie X należy zastąpić usuniętą jednostką.

Jeśli nie masz dostępu do ObjectContextwykonania _context.ChildEntity.Remove(child), możesz rozwiązać ten problem, czyniąc klucz obcy częścią klucza podstawowego w tabeli potomnej.

Parent
 ________________
| PK    IdParent |
|       Name     |
|________________|

Child
 ________________
| PK    IdChild  |
| PK,FK IdParent |
|       Name     |
|________________|

W ten sposób, jeśli wykonasz parent.Remove(child), EF poprawnie oznaczy jednostkę jako usuniętą.

Tego rodzaju rozwiązanie zrobiło dla mnie lewę:

Parent original = db.Parent.SingleOrDefault<Parent>(t => t.ID == updated.ID);
db.Childs.RemoveRange(original.Childs);
updated.Childs.ToList().ForEach(c => original.Childs.Add(c));
db.Entry<Parent>(original).CurrentValues.SetValues(updated);

Ważne jest, aby powiedzieć, że usuwa to wszystkie rekordy i wstawia je ponownie. Ale w moim przypadku (mniej niż 10) jest w porządku.

Mam nadzieję, że to pomoże.

Zetknąłem się dzisiaj z tym problemem i chciałem podzielić się moim rozwiązaniem. W moim przypadku rozwiązaniem było usunięcie elementów podrzędnych przed pobraniem elementu nadrzędnego z bazy danych.

Wcześniej robiłem to tak, jak w poniższym kodzie. Otrzymam ten sam błąd wymieniony w tym pytaniu.

var Parent = GetParent(parentId);
var children = Parent.Children;
foreach (var c in children )
{
     Context.Children.Remove(c);
}
Context.SaveChanges();

To, co zadziałało, to najpierw pobrać elementy potomne, używając ParentId (klucz obcy), a następnie usunąć te elementy. Następnie mogę pobrać Rodzica z bazy danych iw tym momencie nie powinno już mieć żadnych elementów potomnych i mogę dodawać nowe elementy potomne.

var children = GetChildren(parentId);
foreach (var c in children )
{
     Context.Children.Remove(c);
}
Context.SaveChanges();

var Parent = GetParent(parentId);
Parent.Children = //assign new entities/items here

Musisz ręcznie wyczyścić kolekcję ChildItems i dołączyć do niej nowe elementy:

thisParent.ChildItems.Clear();
thisParent.ChildItems.AddRange(modifiedParent.ChildItems);

Następnie możesz wywołać metodę rozszerzenia DeleteOrphans, która będzie obsługiwać osierocone jednostki (musi być wywołana między metodami DetectChanges i SaveChanges).

public static class DbContextExtensions
{
    private static readonly ConcurrentDictionary< EntityType, ReadOnlyDictionary< string, NavigationProperty>> s_navPropMappings = new ConcurrentDictionary< EntityType, ReadOnlyDictionary< string, NavigationProperty>>();

    public static void DeleteOrphans( this DbContext source )
    {
        var context = ((IObjectContextAdapter)source).ObjectContext;
        foreach (var entry in context.ObjectStateManager.GetObjectStateEntries(EntityState.Modified))
        {
            var entityType = entry.EntitySet.ElementType as EntityType;
            if (entityType == null)
                continue;

            var navPropMap = s_navPropMappings.GetOrAdd(entityType, CreateNavigationPropertyMap);
            var props = entry.GetModifiedProperties().ToArray();
            foreach (var prop in props)
            {
                NavigationProperty navProp;
                if (!navPropMap.TryGetValue(prop, out navProp))
                    continue;

                var related = entry.RelationshipManager.GetRelatedEnd(navProp.RelationshipType.FullName, navProp.ToEndMember.Name);
                var enumerator = related.GetEnumerator();
                if (enumerator.MoveNext() && enumerator.Current != null)
                    continue;

                entry.Delete();
                break;
            }
        }
    }

    private static ReadOnlyDictionary<string, NavigationProperty> CreateNavigationPropertyMap( EntityType type )
    {
        var result = type.NavigationProperties
            .Where(v => v.FromEndMember.RelationshipMultiplicity == RelationshipMultiplicity.Many)
            .Where(v => v.ToEndMember.RelationshipMultiplicity == RelationshipMultiplicity.One || (v.ToEndMember.RelationshipMultiplicity == RelationshipMultiplicity.ZeroOrOne && v.FromEndMember.GetEntityType() == v.ToEndMember.GetEntityType()))
            .Select(v => new { NavigationProperty = v, DependentProperties = v.GetDependentProperties().Take(2).ToArray() })
            .Where(v => v.DependentProperties.Length == 1)
            .ToDictionary(v => v.DependentProperties[0].Name, v => v.NavigationProperty);

        return new ReadOnlyDictionary<string, NavigationProperty>(result);
    }
}

Wypróbowałem te rozwiązania i wiele innych, ale żadne z nich się nie udało. Ponieważ jest to pierwsza odpowiedź w Google, dodam tutaj moje rozwiązanie.

Metodą, która działała dla mnie dobrze, było usunięcie relacji z obrazu podczas zatwierdzeń, więc EF nie miał nic do zepsucia. Zrobiłem to, ponownie wyszukując obiekt nadrzędny w DBContext i usuwając to. Ponieważ właściwości nawigacyjne ponownie znalezionego obiektu są zerowe, relacje dzieci są ignorowane podczas zatwierdzania.

var toDelete = db.Parents.Find(parentObject.ID);
db.Parents.Remove(toDelete);
db.SaveChanges();

Należy pamiętać, że zakłada to, że klucze obce są skonfigurowane przy użyciu opcji USUŃ KASKADĘ, więc po usunięciu wiersza nadrzędnego dzieci zostaną wyczyszczone przez bazę danych.

Użyłem rozwiązania Mosha , ale nie było dla mnie oczywiste, jak najpierw poprawnie zaimplementować klucz kompozycji w kodzie.

Oto rozwiązanie:

public class Holiday
{
    [Key, Column(Order = 0), DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int HolidayId { get; set; }
    [Key, Column(Order = 1), ForeignKey("Location")]
    public LocationEnum LocationId { get; set; }

    public virtual Location Location { get; set; }

    public DateTime Date { get; set; }
    public string Name { get; set; }
}

Miałem ten sam problem, ale wiedziałem, że działał OK w innych przypadkach, więc zredukowałem problem do tego:

parent.OtherRelatedItems.Clear();  //this worked OK on SaveChanges() - items were being deleted from DB
parent.ProblematicItems.Clear();   // this was causing the mentioned exception on SaveChanges()

• OtherRelatedItems miał złożony klucz podstawowy (parentId + część lokalnej kolumny) i działał OK
• ProblematicItems miały własny jednokolumnowy klucz podstawowy, a parentId był tylko FK. Powodowało to wyjątek po Clear ().

Wszystko, co musiałem zrobić, to uczynić ParentId częścią złożonej PK, aby wskazać, że dzieci nie mogą istnieć bez rodzica. Użyłem modelu DB-first, dodałem PK i oznaczyłem kolumnę parentId jako EntityKey (więc musiałem zaktualizować go zarówno w DB, jak i EF - nie jestem pewien, czy wystarczy EF).

Kiedy się nad tym zastanowisz, jest to bardzo eleganckie rozróżnienie, którego EF używa do decydowania, czy dzieci „mają sens” bez rodzica (w tym przypadku Clear () nie usunie ich i nie wyrzuci wyjątku, chyba że ustawisz ParentId na coś innego / specjalnego ) lub - jak w pierwotnym pytaniu - oczekujemy, że elementy zostaną usunięte po usunięciu z elementu nadrzędnego.

Ten problem powstaje, ponieważ próbujemy usunąć tabelę nadrzędną, nadal istnieją dane tabeli podrzędnej. Rozwiązujemy problem za pomocą kasowania.

W modelu Utwórz metodę w klasie dbcontext.

 modelBuilder.Entity<Job>()
                .HasMany<JobSportsMapping>(C => C.JobSportsMappings)
                .WithRequired(C => C.Job)
                .HasForeignKey(C => C.JobId).WillCascadeOnDelete(true);
            modelBuilder.Entity<Sport>()
                .HasMany<JobSportsMapping>(C => C.JobSportsMappings)
                  .WithRequired(C => C.Sport)
                  .HasForeignKey(C => C.SportId).WillCascadeOnDelete(true);

Następnie w naszym wywołaniu API

var JobList = Context.Job                       
          .Include(x => x.JobSportsMappings)                                     .ToList();
Context.Job.RemoveRange(JobList);
Context.SaveChanges();

Opcja usuwania kaskadowego pozwala usunąć tabelę podrzędną nadrzędną i nadrzędną za pomocą tego prostego kodu. Spróbuj w ten prosty sposób.

Usuń zakres, który został użyty do usunięcia listy rekordów w bazie Dzięki

Rozwiązałem również mój problem z odpowiedzią Mosha i pomyślałem, że odpowiedź PeteraB była nieco inna, ponieważ używał wyliczenia jako klucza obcego. Pamiętaj, że musisz dodać nową migrację po dodaniu tego kodu.

Mogę również polecić ten post na blogu, aby znaleźć inne rozwiązania:

http://www.kianryan.co.uk/2013/03/orphaned-child/

Kod:

public class Child
{
    [Key, Column(Order = 0), DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int Id { get; set; }

    public string Heading { get; set; }
    //Add other properties here.

    [Key, Column(Order = 1)]
    public int ParentId { get; set; }

    public virtual Parent Parent { get; set; }
}

Korzystając z rozwiązania Slauma, stworzyłem ogólne funkcje, które pomagają aktualizować obiekty potomne i kolekcje obiektów potomnych.

Wszystkie moje trwałe obiekty implementują ten interfejs

/// <summary>
/// Base interface for all persisted entries
/// </summary>
public interface IBase
{
    /// <summary>
    /// The Id
    /// </summary>
    int Id { get; set; }
}

Dzięki temu zaimplementowałem te dwie funkcje w moim repozytorium

    /// <summary>
    /// Check if orgEntry is set update it's values, otherwise add it
    /// </summary>
    /// <param name="set">The collection</param>
    /// <param name="entry">The entry</param>
    /// <param name="orgEntry">The original entry found in the database (can be <code>null</code> is this is a new entry)</param>
    /// <returns>The added or updated entry</returns>
    public T AddOrUpdateEntry<T>(DbSet<T> set, T entry, T orgEntry) where T : class, IBase
    {
        if (entry.Id == 0 || orgEntry == null)
        {
            entry.Id = 0;
            return set.Add(entry);
        }
        else
        {
            Context.Entry(orgEntry).CurrentValues.SetValues(entry);
            return orgEntry;
        }
    }

    /// <summary>
    /// check if each entry of the new list was in the orginal list, if found, update it, if not found add it
    /// all entries found in the orignal list that are not in the new list are removed
    /// </summary>
    /// <typeparam name="T">The type of entry</typeparam>
    /// <param name="set">The database set</param>
    /// <param name="newList">The new list</param>
    /// <param name="orgList">The original list</param>
    public void AddOrUpdateCollection<T>(DbSet<T> set, ICollection<T> newList, ICollection<T> orgList) where T : class, IBase
    {
        // attach or update all entries in the new list
        foreach (T entry in newList)
        {
            // Find out if we had the entry already in the list
            var orgEntry = orgList.SingleOrDefault(e => e.Id != 0 && e.Id == entry.Id);

            AddOrUpdateEntry(set, entry, orgEntry);
        }

        // Remove all entries from the original list that are no longer in the new list
        foreach (T orgEntry in orgList.Where(e => e.Id != 0).ToList())
        {
            if (!newList.Any(e => e.Id == orgEntry.Id))
            {
                set.Remove(orgEntry);
            }
        }
    }

Aby go użyć, wykonaj następujące czynności:

var originalParent = _dbContext.ParentItems
    .Where(p => p.Id == parent.Id)
    .Include(p => p.ChildItems)
    .Include(p => p.ChildItems2)
    .SingleOrDefault();

// Add the parent (including collections) to the context or update it's values (except the collections)
originalParent = AddOrUpdateEntry(_dbContext.ParentItems, parent, originalParent);

// Update each collection
AddOrUpdateCollection(_dbContext.ChildItems, parent.ChildItems, orgiginalParent.ChildItems);
AddOrUpdateCollection(_dbContext.ChildItems2, parent.ChildItems2, orgiginalParent.ChildItems2);

Mam nadzieję że to pomoże

DODATKOWE: Możesz także utworzyć osobną klasę DbContextExtentions (lub własną kontekstową warstwę):

public static void DbContextExtentions {
    /// <summary>
    /// Check if orgEntry is set update it's values, otherwise add it
    /// </summary>
    /// <param name="_dbContext">The context object</param>
    /// <param name="set">The collection</param>
    /// <param name="entry">The entry</param>
    /// <param name="orgEntry">The original entry found in the database (can be <code>null</code> is this is a new entry)</param>
    /// <returns>The added or updated entry</returns>
    public static T AddOrUpdateEntry<T>(this DbContext _dbContext, DbSet<T> set, T entry, T orgEntry) where T : class, IBase
    {
        if (entry.IsNew || orgEntry == null) // New or not found in context
        {
            entry.Id = 0;
            return set.Add(entry);
        }
        else
        {
            _dbContext.Entry(orgEntry).CurrentValues.SetValues(entry);
            return orgEntry;
        }
    }

    /// <summary>
    /// check if each entry of the new list was in the orginal list, if found, update it, if not found add it
    /// all entries found in the orignal list that are not in the new list are removed
    /// </summary>
    /// <typeparam name="T">The type of entry</typeparam>
    /// <param name="_dbContext">The context object</param>
    /// <param name="set">The database set</param>
    /// <param name="newList">The new list</param>
    /// <param name="orgList">The original list</param>
    public static void AddOrUpdateCollection<T>(this DbContext _dbContext, DbSet<T> set, ICollection<T> newList, ICollection<T> orgList) where T : class, IBase
    {
        // attach or update all entries in the new list
        foreach (T entry in newList)
        {
            // Find out if we had the entry already in the list
            var orgEntry = orgList.SingleOrDefault(e => e.Id != 0 && e.Id == entry.Id);

            AddOrUpdateEntry(_dbContext, set, entry, orgEntry);
        }

        // Remove all entries from the original list that are no longer in the new list
        foreach (T orgEntry in orgList.Where(e => e.Id != 0).ToList())
        {
            if (!newList.Any(e => e.Id == orgEntry.Id))
            {
                set.Remove(orgEntry);
            }
        }
    }
}

i używaj go w następujący sposób:

var originalParent = _dbContext.ParentItems
    .Where(p => p.Id == parent.Id)
    .Include(p => p.ChildItems)
    .Include(p => p.ChildItems2)
    .SingleOrDefault();

// Add the parent (including collections) to the context or update it's values (except the collections)
originalParent = _dbContext.AddOrUpdateEntry(_dbContext.ParentItems, parent, originalParent);

// Update each collection
_dbContext.AddOrUpdateCollection(_dbContext.ChildItems, parent.ChildItems, orgiginalParent.ChildItems);
_dbContext.AddOrUpdateCollection(_dbContext.ChildItems2, parent.ChildItems2, orgiginalParent.ChildItems2);

Miałem ten sam problem, kiedy zamierzam usunąć mój rekord, niż pojawił się jakiś problem, ponieważ w przypadku tego rozwiązania problemu, gdy masz zamiar usunąć swój rekord, niż czegoś brakuje przed usunięciem nagłówka / rekordu głównego, musisz napisać w kodzie dla usuń jego szczegóły przed nagłówkiem / Master Mam nadzieję, że problem zostanie rozwiązany.

Problem ten spotkałem przed kilkoma godzinami i próbowałem wszystkiego, ale w moim przypadku rozwiązanie różniło się od powyższego.

Jeśli użyjesz już pobranej encji z bazy danych i spróbujesz zmodyfikować jej potomek, wystąpi błąd, ale jeśli otrzymasz nową kopię encji z bazy danych, nie powinno być żadnych problemów. Nie używaj tego:

 public void CheckUsersCount(CompanyProduct companyProduct) 
 {
     companyProduct.Name = "Test";
 }

Użyj tego:

 public void CheckUsersCount(Guid companyProductId)
 {
      CompanyProduct companyProduct = CompanyProductManager.Get(companyProductId);
      companyProduct.Name = "Test";
 }