вы сами можете решить: использовать хуки или триггеры в вашей инфрастуктуре
но использовать хуки - куда легче, так как сразу видишь в коде, что происходит, а триггеры, если их нет в vcs (когда бд была еще до приложения), нужно дебажить и додумываться, что есть триггер, который как-то неадекватно ломает логику
> сложные вещи я кладу рядом в основном коде. Пример из пальца: создали юзера - отправили мейл. У меня отправка мейла не будет лежать в хуке на сохранение юзера, а в том месте, где мы его сохраняем, рядом будет вызов на мейлер.
скорее всего вы не будете напрямую вызывать функцию "отослать эмейл"
но можно в хуке прописать "поставить в очередь задание послать юзеру эмейл", что божественно удобно
> тогда это везде баг и “непозволительно”. В любом ОРМе на любом зыке если ты через raw запрос изменишь значение в базе, поле updatedAt не поменяется.
нет, вы неправильно поняли, о чем я говорю
у ормы есть фича добавить декоратор на аттрибут модели, чтобы определить ее как createdAt/updatedAt/deletedAt и сама орм занимается их обновлением, согласно ее документации.
в тайпорме это тоже прописано, но на практике не работает :)
причем тут raw запрос вообще не понял, мы ведь про ормки говорим
с другим всем согласен
> у ормы есть фича добавить декоратор на аттрибут модели, чтобы определить ее как createdAt/updatedAt/deletedAt и сама орм занимается их обновлением, согласно ее документации.
в тайпорме это тоже прописано, но на практике не работает :)
Ну почему же, createdAt работает, правда в mysql (в pg такого нет) при вставке за раз 1000 строк ты получишь ещё 1000 select'ов, причём идентичных. Я ловил и другие баги, но после этого сгорел окончательно (
https://github.com/typeorm/typeorm/issues/6266). И кстати queryBuilder на insert в этом кейсе тоже багнутый.
Если бы я выбирал orm для node, то смотрел бы на prisma 2.x, хотя может там тоже будет весело, ещё плотно не работал.