Dokumentacja Apple zawiera świetny przykład, który sugeruje sytuację, w której możesz mieć problemy, nie mając odwrotnej zależności. Zmapujmy to w tym przypadku.
Załóżmy, że zaprojektowałeś to w następujący sposób:
Zauważ, że istnieje relacja do jednego zwana „ typem ”, od SocialAppdo SocialAppType. Relacja nie jest opcjonalna i ma regułę usuwania „odmów” .
Rozważmy teraz następujące kwestie:
SocialApp *socialApp;
SocialAppType *appType;
// assume entity instances correctly instantiated
[socialApp setSocialAppType:appType];
[managedObjectContext deleteObject:appType];
BOOL saved = [managedObjectContext save:&error];
Oczekujemy, że ten kontekst nie zostanie zapisany, ponieważ ustawiliśmy regułę usuwania jako Odmów, podczas gdy relacja nie jest opcjonalna.
Ale tutaj zapis się udaje.
Powodem jest to, że nie ustawiliśmy odwrotnej zależności . Z tego powodu instancja aplikacji społecznościowej nie jest oznaczana jako zmieniona po usunięciu appType. Dlatego przed zapisaniem aplikacji społecznościowej nie jest przeprowadzana weryfikacja (zakłada ona, że nie jest wymagana weryfikacja, ponieważ nie nastąpiła żadna zmiana). Ale tak naprawdę nastąpiła zmiana. Ale to się nie odbija.
Jeśli przypomnimy sobie appType według
SocialAppType *appType = [socialApp socialAppType];
appType ma wartość nil.
Dziwne, prawda? Otrzymujemy zero dla atrybutu nie opcjonalnego?
Więc nie masz kłopotów, jeśli ustawiłeś odwrotną zależność. W przeciwnym razie musisz wymusić walidację, pisząc kod w następujący sposób.
SocialApp *socialApp;
SocialAppType *appType;
// assume entity instances correctly instantiated
[socialApp setSocialAppType:appType];
[managedObjectContext deleteObject:appType];
[socialApp setValue:nil forKey:@"socialAppType"]
BOOL saved = [managedObjectContext save:&error];
