Core Data использует обратные отношения и правила удаления, чтобы поддерживать согласованность графа объектов.
Допустим, у вас есть A.foo ‹11> B.bar и вы делаете a.foo = b
. Это автоматически (эффективно) выполняет b.bar = a
.
Теперь скажем, вы [b delete]
. С правилом «аннулировать» эффективно делает b.bar.foo = nil
. С "каскадом" это [b.bar delete]
. Без действия ничего не происходит; a.foo
теперь является «висячей ссылкой на объект Core Data».
На самом деле это не болтающийся указатель; стандартные правила управления памятью означают, что b
все еще будет существовать в памяти, пока a
указывает на него (пока a
не превратится в ошибку), но a.foo
навсегда будет ссылаться на удаленный объект, что вызывает исключение при попытке доступа к его свойствам. Я тоже не знаю, что происходит, когда вы сохраняете и повторно загружаете a
.
С отношениями «многие ко многим» все становится сложнее. Сведения о реализации: похоже, что отношение "принадлежит" одному из объектов и сохраняется только при сохранении этого объекта (я столкнулся с этой ошибкой при попытке установить отношение между разными MOC: Сохраненный MOC не владел обновленной сущностью, поэтому отношение никогда не сохранялось). Очевидно, что когда вы удаляете оба a
и b
, связи также должны быть удалены, поэтому предполагается, что связь исчезает, удаляется только одна из них (но вы не знаете, какая именно!).
Вы, вероятно, хотите Nullify или Cascade. Я никогда не использую Cascade, потому что никогда не могу вспомнить, в каком направлении происходит каскадирование.
person
tc.
schedule
12.04.2011