в данном случае емейл уже занят и правильным было бы сначала проверить это, перед тем как делать инсерт… тогда орм-ке не нужно будет выбрасывать ошибку, ты её заранее обработаешь и вернёшь клиенту…

@constb
У меня в текущем запросе может быть не одна ошибка, я хотел все ошибки из бд собрать в одном месте для форматирования и отправки на клиент.
Допустим у меня в том же запросе есть еще и такая ошибка:

insert or update on table "user" violates foreign key constraint "FK_974590e8d8d4ceb64e30c38e051"

При этом мне нужно сделать запрос на проверку нету ли такого email и проверку если ли id для связи в другой таблице.

По этому поводу есть несколько вопросов:
1. В итоге перед инсертом сделать 2 запроса в бд(ради валидации) - это нормальная практика ?
2. Доводить orm до выбрасывания exception - плохая практика ?

1) нормальная
2) тоже нормально – но сложнее обрабатывать чем первый вариант…

обычно такие проверки делаются как часть валидации входящих данных

@constb спасибо, пошел ковыряться)

А чо-чо upsert сюда не завезли?

мб из за того что очень субд зависимая хрень

если речь о регистрации пользователя – апсерт тут как бы совсем не в тему 🙂 функционал «угона аккаунта» штатно реализовывать в системе – несколько непрактично будет 🙂

insert or update on table "user" violates foreign key constraint "FK_974590e8d8d4ceb64e30c38e051"

ну тут надо смотреть за и против
везде есть компромиссы
обычно надо делать до базы валидацию что бы туда попадали только валидные данные

а бывает и пофиг на данные если не будут записаны

Я не заметил, что речь про регистрацию

@jashka_jashka
Ну я для себя выбрал с помощью class-validator насобирать кастомных правил для валидации.
т.к. хочу организовать обработку ошибок для graphql как в статье у Паши. (https://github.com/nodkz/conf-talks/tree/master/articles/graphql/errors) - очень уж красиво.

И не все ошибки могу красиво отдать из-за отсутствия некоторых данных в ошибках возвращенных базой(хз, ORM не всё отдает или не неё проблема).

есть валидация входных запросов, есть инварианты, есть бизнес правила
я типа не юзаю декораторы для валидации, @hapi/joi хватает с головой, схема отдельно лежит

у меня type-graphql и nestjs там красиво с class-validator 🙂

я отказался от type-graphql в пользу схемы
потому что как ты добавишь кастомные директивы и навесишь на них обработчик ?

class-validator накидыватся на input-типы и валидирует входные данные без особых проблем. мне в class-validator показались ограниченными стандартный набор валидаторов и возможности их комбинирования тоже как-то не очень… при этом кастомные писать не сказать чтобы удобно… но жить можно…

если на вход залетают обычные объекты или их нужно отдельно конвертировать в валидируемые классы – class-transformer плюс class-transformer-validator решают эту задачу…

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

еще не успел задаться этим вопросом 🙂

вообще кастомные валидаторы умеют делать условную валидацию по соседним полям. да там вроде и среди стандартных что-то такое было… другое дело что могут быть сложные условия, которые вообще применяются не к конкретным полям – но тут наверное надо помнить что class-validator не совсем уж универсальный комбайн для всего – какие-то вещи быстрее и проще сделать уже как часть логики обработчиков…

вообще наверное надо быть проще. если не можешь вспомнить что и как делается с декораторами валидатора, наверное быстрее будет просто дописать пару строк в отдельный класс и не заниматься оверинжинирингом… а ещё в пакете class-validator полезно заглядывать в файлик validation/validator.ts – некоторые валидаторы имеют интересные побочные эффекты или способы реализации или ограничения, которые могут оказаться сюрпризом 🙂