ПГ
Есть еще вариант, люди так делают: выбрать все записи и в цикле проверить каждую
Сарказм засчитан
Size: a a a
2020 December 19
MM
Это не сарказм
ВУ
что касается ещё понимая того, что именно зафейлилось. если ты стейт декомпозируешь достаточно сильно, что в каждом юзкейсе у тебя совсем мало вариантов остаётся, что именно могло нарушиться.
ВУ
а если у тебя табличка на 100 колонок и там 500 констрейнтов и внешних ключей на всю базу, то, конечно, трудно будет)) но не поэтому, а вообще
ПГ
что касается ещё понимая того, что именно зафейлилось. если ты стейт декомпозируешь достаточно сильно, что в каждом юзкейсе у тебя совсем мало вариантов остаётся, что именно могло нарушиться.
мало !=1
ВУ
Кейс вопроса выше, уникальный ИНН, но есть еще и email. Вышибло sql искать conatraint_email_unique или constraint_inn_unique в ответе sql чтобы сформировать ошибку?
у тебя не должны лежать email и ИНН в одном агрегате таблице, потому что я не могу себе представить, какой инвариант они образуют совместно
S
Кейс вопроса выше, уникальный ИНН, но есть еще и email. Вышибло sql искать conatraint_email_unique или constraint_inn_unique в ответе sql чтобы сформировать ошибку?
В моем кейсе думаю не важно, какое поле дублируется . Можно просто выводить что-то типо - Ошибка регистрации клиента, клиент уже зарегистрирован.
ПГ
у тебя не должны лежать email и ИНН в одном агрегате таблице, потому что я не могу себе представить, какой инвариант они образуют совместно
Ок. Т.е. у вас всегда максимум один констрейнт на таблицу и больше не никогда бывает?
S
у тебя не должны лежать email и ИНН в одном агрегате таблице, потому что я не могу себе представить, какой инвариант они образуют совместно
Там был инн и кпп)
ПГ
у тебя не должны лежать email и ИНН в одном агрегате таблице, потому что я не могу себе представить, какой инвариант они образуют совместно
Опять таки. Таблиц может быть много маленьких, а запросов к разным табилицам в одной транзаакции - тоже и там несколько коснтерйтов
ВУ
в крайнем случае нет ничего плохого сделать
catch (ConstraintViolationException $exception) {
if (str_contains($exception->getMessage(), 'email_unique_key')) {
throw new EmailNonUnique()
}
if (str_contains($exception->getMessage(), 'inn_unique_key')) {
throw new InnNonUnique()
}
throw $exception;
}ВУ
тут как бы не промажешь
ПГ
в крайнем случае нет ничего плохого сделать
catch (ConstraintViolationException $exception) {
if (str_contains($exception->getMessage(), 'email_unique_key')) {
throw new EmailNonUnique()
}
if (str_contains($exception->getMessage(), 'inn_unique_key')) {
throw new InnNonUnique()
}
throw $exception;
}Ок спасибо, типо это нормальный кейс в "мире больших дядей" ? :)
ВУ
но я бы сделал так. сначала бы вообще болт забил и залил без всяких преобразований исключений. если стреляет чаще, чем два раза в год (в чём я сомневаюсь), сделал бы как выше показал
ВУ
Ок спасибо, типо это нормальный кейс в "мире больших дядей" ? :)
а что тебе не нравится? какой принцип это нарушает? ну кроме того, что inn и email кто-то забыл разделить на разные модули
ВУ
главное, чтобы этот catch с обертками был на том же уровне, на каком появляется DBAL (виидимо, имплементация репозитория). и чтобы твои кастомные исключения участвовали в контракте репозитория через @throws, чтобы это ни для кого секретом не было. тогда всё ок будет
ПГ
а что тебе не нравится? какой принцип это нарушает? ну кроме того, что inn и email кто-то забыл разделить на разные модули
Ничего, я просто удостверяюсь что понял идею правильно. А то мб речь обо одном, я пойму по другому и в тоге какую то херню буду писать :)