A documentação da Apple tem um ótimo exemplo que sugere uma situação em que você pode ter problemas por não ter um relacionamento inverso. Vamos mapeá-lo neste caso.
Suponha que você modelou da seguinte maneira:
Observe que você tem um relacionamento pessoal chamado " tipo ", de SocialApppara SocialAppType. O relacionamento não é opcional e possui uma regra de exclusão "negar" .
Agora considere o seguinte:
SocialApp *socialApp;
SocialAppType *appType;
// assume entity instances correctly instantiated
[socialApp setSocialAppType:appType];
[managedObjectContext deleteObject:appType];
BOOL saved = [managedObjectContext save:&error];
O que esperamos é deixar de salvar o contexto, pois definimos a regra de exclusão como Negar, enquanto o relacionamento não é opcional.
Mas aqui a defesa é bem-sucedida.
A razão é que não estabelecemos um relacionamento inverso . Por esse motivo, a instância socialApp não é marcada como alterada quando appType é excluído. Portanto, nenhuma validação acontece para o socialApp antes de salvar (ela não assume nenhuma validação necessária, pois nenhuma alteração ocorreu). Mas, na verdade, uma mudança aconteceu. Mas isso não se reflete.
Se lembrarmos de appType por
SocialAppType *appType = [socialApp socialAppType];
appType é nulo.
Estranho, não é? Ficamos nulos por um atributo não opcional?
Portanto, você não terá problemas se tiver estabelecido um relacionamento inverso. Caso contrário, você precisará forçar a validação escrevendo o código da seguinte maneira.
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];
