D7 ORM - ON DELETE CASCADE
Идея, которую хотелось бы тут изложить, не нова, но руки никак до нее не доходили.
Навеяна она сообщением на форуме:
В sql есть "каскадные операции" - удаление связанных записей или обновлние.
И хотя сейчас я слабо представляю каскадное обновление, но вот каскадное удаление или запрет на изменение/удаление уже отчетливо видно.
Прошу рассмотреть возможность реализации данной функциональности.
Навеяна она сообщением на форуме:
В sql есть "каскадные операции" - удаление связанных записей или обновлние.
И хотя сейчас я слабо представляю каскадное обновление, но вот каскадное удаление или запрет на изменение/удаление уже отчетливо видно.
Прошу рассмотреть возможность реализации данной функциональности.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
Не будет такого. Битрикс API (серверное) написано на PHP. Так что каскадов ждать не надо.
к тому же это не перенос API в БД, т.к. все те же методы останутся, просто для удаления связей не нужно будет вызывать 100-500 функций в транзакции
Да, всю логику выносить туда бессмысленно, но есть базовые операции, которые она умеет делать хорошо.
Каскадные операции это то же что и JOIN. Вы же не делаете JOIN средствами PHP ?
Для выборки одного логически связанного набора данных частенько приходится использовать несколько вызовов API Битрикс (в том числе с целью соединений). А это, несомненно, несколько разных запросов. Так что да, ответ утвердительный.
Более того, часто случается так, что один навороченный запрос будет выполняться в десятки раз дольше пары-тройки более простых (приводящих к соединению средствами PHP).
Возможно, когда ORM станет полноценным (видимо, объектным), эти выкрутасы будут скрыты внутри API Битрикс и достаточно будет одного вызова. Но пока так. И сколько это продлится в годах - не знаю.
Во-вторых, мое субективное мнение, что Вы не работали на проектах, где таких "misc" таблиц много и по невнимательности разработчика или каких-либо внешних факторов они распухают.
В-третьих, хотите ли Вы нарваться на такой модуль или нет, это сугубо Ваши предпочтения. Мне вот лично это важнее чем "видеофиксирование переговоров" в Б24, но опять же - это мое личное мнение, так же как и Ваше отношение к каскадам - Ваше мнение.
Если Вы знаете отличия каскадных операций на MSSQL, Oracle и MySQL, я был бы благодарен, если бы Вы поделились этой информацией.
Хотя при таком подходе автор решения будет рекомендовать лезть напрямую в таблицы ... Что в принципе в Битрикс не приветствуется (граничит с профнепригодностью такой прием).
Я то выкручусь, в конце концов. После затребованных Вами изменений в ORM вообще ни одно решение не куплю без раскопок. А будет настаивать владелец сайта на определенном решении потому, что "проблему решает" - это будет уже его проблема. Моя - только предупредить о последствиях.
Здесь консенсуса не будет. Эмоции не помогут. Только голосование. Ну, наголосуют, что это круто. Да до такой степени, что контора возьмет под козырек, тогда появится Битрикс SQL (как когда-то на .Net делали).
Сейчас я вижу со всей определенность, что очень круто, что контора не обязана реализовывать все идеи. Нравится, видят в этом смысл, укладывается в архитектурное решение, будет иметь коммерческий эффект - будет реализовано.