Удалить правила для отношений «один-на-один»

Документация Apple относительно правил удаления отношений проста и понятна. Но это говорит только об отношениях « один-ко-многим» («Удалить правила для отношений« один-к-одному » легко вывести). Непонятно, что означают эти правила для отношений « многие-к-одному» . Поэтому давайте проясним их здесь.

Мы используем пример Employees-Department, используемый в документации Apple. Хотя реальные последствия могут быть смехотворными в отношении этих правил, применяемых к отношениям Сотрудники-Департамент , мы, как программисты, говорим только о своих логических последствиях здесь.

  • Отрицать
    Если в назначении отношения есть объект, то исходный объект не может быть удален.

    Например, если вы хотите удалить сотрудника, независимо от того, есть ли другие сотрудники в его отделе, вы должны убедиться, что отдел сначала удален, иначе сотрудник не может быть удален.

  • сводить на нет
    Удалите исходный объект из обратного отношения объекта к месту назначения. (См. Краткое объяснение @ bshirley)

    Например, если вы удаляете сотрудника, удалите его из отношений сотрудников его отдела. Это имеет смысл только в том случае, если количество оставшихся сотрудников отдела больше необходимого минимального количества или если вы добавите новых сотрудников для отдела до следующей операции сохранения.

    [ Вопрос : Если это последний сотрудник, отношения сотрудников отдела станут пустыми или пустыми?]
    (Ответа на этот вопрос @TechZen: Отношение A to-many всегда возвращает заданный объект. Это никогда не будет nil. Если на другой стороне отношения нет объектов, набор пуст.)

  • Каскад Удалите объект в месте назначения.

    Например, если вы удаляете сотрудника, удалите его отдел в одно и то же время, даже если в отделе есть еще другие сотрудники.

    ( Оговорка об использовании : обычно он вызывает «цепочку делегирования по всему графику объекта», как описано в этом примере в @TechZen.)

  • Бездействие
    Не делайте ничего для объекта в месте назначения.

    Например, если вы удаляете сотрудника, оставьте его отдел таким, какой он есть, даже если он все еще считает, что он владеет этим сотрудником.

Из этого можно вывести значения правил удаления правил для отношений « многие ко многим» .

Это правила удаления для всех отношений (а не атрибутов). Они применимы для отношений «один или ко многим» .

  • Nullify – если вы удаляете сотрудника, обратная связь устанавливается равной нулю , если это было 1-к-1, то буквально, в этом случае сотрудники отдела сокращаются на один

  • Каскад – если вы удалите сотрудника, его отдел будет удален. Департамент будет следовать правилу удаления во всех его свойствах: 1) если правило удаления служащих было Cascade, все сотрудники будут удалены этим действием; 2) если сотрудники удалили правило, было Nullify, все сотрудники были бы «застряли» без отдела

Вы, кажется, предполагаете, что есть некоторые изменения в поведении правил удаления между «один-ко-многим» и «много-к-одному», но их нет. Все работает точно так же. Если вы думаете об этом, то это должно быть так, потому что «один ко многим» – это просто взаимные отношения много-к-одному.

Я думаю, что это идея взаимных отношений, которая вас трогает. Каждая сторона отношения определяется отдельно и имеет свое собственное правило удаления, которое может отличаться от правила удаления с другой стороны.

Рассмотрим пример стандартного отдела и сотрудника.

Department{ name:string employees<--(required,cascade)-->>Employee.department } Employee{ name:string department<<--(required, nullify)-->Department.employee projects<--(optional,cascade)-->>Project.owner } Project{ name: owner<<--(required,nullify)-->Employee.projects } 

Обратите внимание, что каждое отношение, каждая строка стрелки в графической модели, имеет два описания, связанные с ним в взаимном соотношении (которое является стандартной формой.) Каждое описание описывает взаимосвязь «перспективы» одного из связанных объектов. Таким образом, каждое отношение «один ко многим» – это всего лишь обратная связь между отношениями «один-ко-многим».

Кроме того, необязательный / обязательный / mincount отношения to-many на стороне могут блокировать удаление объектов с другой стороны.

Возьмите Отдел <- >> Сотрудник. С точки зрения Департамента, объект Департамента должен иметь как минимум одного сотрудника. Если у него только один сотрудник, то этот сотрудник не может быть удален. Если сам объект Департамента удаляется, все его сотрудники также удаляются. С точки зрения работника каждый сотрудник должен иметь отдельный отдел. Любая попытка сохранить значение nil для значения отдела объекта сотрудника приведет к ошибке проверки. Однако, если объект employee удален, то ничего не происходит с объектом отдела вообще, за исключением того, что он теряет один из своих объектов-сотрудников. Однако, если объект employee является единственным объектом-сотрудником в этой связи, объект «Департамент» блокирует удаление.

Каскадное удаление, как следует из названия, может задавать цепочку делегирования по всей диаграмме объектов. Когда вы удаляете объект «Департамент», он удаляет все связанные с ним объекты Employee, каждый из которых, в свою очередь, удаляет все объекты Project.

Но что, если у вас есть правило каскадного удаления, установленное с обеих сторон отношения «многие ко многим», например:

 Alpha{ betas<<--(cascade)-->>Beta.alphas } Beta{ alphas<<--(cascade)-->>Alpha.betas } 

В этом случае удаление любого объекта в графе приведет к удалению всех других объектов, связанных либо с ключом. Удаление одного объекта Beta приведет к удалению всех его объектов Alpha, которые, в свою очередь, удалили бы все их бета-объекты, которые, в свою очередь, удалили бы все их объекты Alpha … и так далее, пока все связанные объекты не будут удалены.

Очевидно, что двухстороннее отношение к каскаду – это хороший способ стрелять в ногу.

В суммировании:

  • Отношения определяются по обе стороны отношений каждой сущностью независимо.
  • Правила удаления могут быть переопределены опциональностью или mincounts.
  • Понимание поведения во время выполнения отношений требует объединения эффектов правил удаления, опциональности и mincounts.

Одной из причин создания редактора модели данных было наложение некоторой ограничительной логики на правила отношений, чтобы сохранить / предупредить кодировщиков от создания неожиданных и перекрестных целей.

  • Какой CGImageAlphaInfo мы должны использовать?
  • Будет ли хранилище основных данных NSInMemoryStoreType хранить весь график в памяти и, следовательно, сильно ограничено системной памятью?
  • В Metal, каковы правильные blendFactors для классического композитора Porter-Duff?
  • Отправить String на веб-сервер в iOS?
  • Как локализовать период времени (iOS / OSX)
  • Как распечатать все содержимое WKWebView On и Offscreen OSX и iOS
  • Автоматически использует ли функция «Архив» Xcode «Конфигурация сборки»?
  • Можно ли получить текущее текущее местоположение с помощью iOS Simulator?
  • Удаление SDK iOS из OSX
  • Что эквивалентно для java-интерфейсов или объективных c-протоколов в swift?
  • Есть ли способ сообщить об ошибках в документации Apple?
  • Давайте будем гением компьютера.