Это четвертая часть вводной серии статей о Prisma. Если вы не читали предыдущие статьи, вы можете найти их ниже.

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

В этой статье мы рассмотрим, как это делается с помощью схемы Prisma.

Давайте погрузимся 🤿

Теперь представьте, что должно произойти, если запись пользователя будет удалена из таблицы User. Или что должно произойти, если тег, примененный к записи сообщения, обновится. Системы SQL имеют механизмы для корректной обработки таких сценариев.

В MySQL это может быть реализовано с помощью любого из ссылочных действий: ON UPDATE или ON DELETE.

НА КАСКАД УДАЛЕНИЯ&НА КАСКАД ОБНОВЛЕНИЯ

При удалении записи родительской таблицы, если установлено значение ON DELETE CASCADE, будет автоматически удалена соответствующая строка в дочерней таблице.

Аналогично, forON UPDATE CASCADE сообщает базе данных, что когда в родительской таблице происходит обновление, соответствующие записи в дочерней таблице должны быть сопоставлены с новым значением.

НА УДАЛЕНИЕ SET NULL И НА ОБНОВЛЕНИЕ SET NULL

Подобно CASCADE, мы можем использовать SET NULL для операций удаления и обновления. Столбец внешнего ключа из дочерней таблицы (книги) будет иметь значение NULL при обновлении или удалении родительской записи.

ОГРАНИЧИТЬ И НЕ ДЕЙСТВОВАТЬ

Параметр RESTRICT имеет тот же эффект, что и отсутствие предложений ON DELETE или ON UPDATE. Он отклоняет применение операций удаления или обновления, если у родительского объекта есть связанные дочерние записи.

Параметр NO ACTION имеет определенные отличия в разных ядрах баз данных SQL. Но в MySQL это почти эквивалентно RESTRICT. NO ACTION отклоняет операцию удаления или обновления для родительской таблицы, если в дочерней таблице есть связанное значение внешнего ключа.

Так как же нам установить их с помощью схемы Prisma?

Здесь вступает в действие схема референтных действий в Prisma.

Прежде чем мы переедем, сначала нам нужно обновить нашу версию Prisma. Поскольку ссылочные действия были определены, начиная с Prisma v.2.26.0.

Я обновлю это до последней версии (3.0.2), где ссылочные действия находятся в общедоступной версии. Вы можете сделать это, вручную изменив версию в package.json или просто нажав

npm install prisma@latest --save-dev

Это обновит версию Prisma CLI до последней версии.

Точно так же вам необходимо обновить версию клиента Prisma.

npm install @prisma/client@latest

Если вы столкнулись с ошибками при обновлении версии Prisma, вы можете очистить каталог node_modules и/или npm_cache и повторить попытку.

Теперь ссылочные действия можно определить в атрибуте @relation.

Но подождите… как пост-записи были удалены каскадным образом в первых нескольких статьях? 🤔

До Prisma 2.25.0 выполнялись ссылочные действия по умолчанию.

Вместо этого в последней версии Prisma у нас есть следующие значения по умолчанию.

Чтобы эти значения по умолчанию отразились в нашей базе данных, нам нужно запустить миграцию или выполнить prisma db push.

Давайте выполним миграцию, чтобы отслеживать изменения схемы базы данных.

npx prisma migrate dev --name referential_default_update

Теперь, если вы попытаетесь удалить пользователя, будет выдана ошибка. Давайте сделаем это через Prisma Studio.

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

Подобно обеспечению ссылочной целостности в отношении 1-m, мы можем применить это и к нашему ранее построенному явному отношению m-n.

С этими изменениями,

  • Если вы удалите Пользователя, создавшего Сообщения, соответствующие записи Сообщений будут удалены.
  • Если вы удалите тег или опубликуете соответствующее назначение тега, запись в таблице TagsOnPosts будет удалена.

Если мы использовали неявную связь m-n между тегами и сообщениями, мы не сможем использовать ссылочные действия. Поскольку ссылочные действия в отношении m-n должны применяться к таблице соединения.

Другие доступные ссылочные действия:

  • Restrict : При применении onDelete предотвращает удаление. Если применяется onUpdate, указанное поле не может быть обновлено.
  • NoAction: аналогично Restrict. Однако существуют различия в зависимости от базы данных, в которой он используется.
  • SetNull : скалярное поле, на которое указывает ссылка, будет установлено в значение null, если оно применяется при удалении или при обновлении.
  • SetDefault : скалярное поле, на которое указывает ссылка, будет установлено по умолчанию, если оно применяется при удалении или при обновлении.

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

Дополнительные материалы на plainenglish.io