Не подскажите как мне сократить и оптимизировать данный код? Не

по душе ом не что то
https://www.toptal.com/developers/hastebin/uherozizam.kotlin

на котлин переписать

Не я выбирал какой язык сайт орпределить для моего кода))

Единственное, можно сделать отдельный сервис, который проверяет есть или нет похожих username/email, и который также сам создаёт объект в базе. То есть, если вы поменяете базу, то контроллеры не сломаются если API от сервиса останется такое же. И тестировать будет легче

запросить за один раз все, что тебе нужно

это судя по всему его сервис. просто он там юзает почему-то DTO

nestjs по умолчанию его создает

а. просто сервис не должно знать вообще о слое контроллера

Выкинуть проверки, потому что они лишены смысла: между проверкой и созданием записи кто-то другой может уже создать запись с таким имейлом или неймом

может. но это корнер кейс. так хотя бы юзер френдли ошибки отдаются

Вообще никакой связи между проверками и тем, что отдаётся на фронт

ок. а как ты тогда скажешь фронту, что имейл уже используется?

Проанализирую исключение и сформирую нужный ответ

Т.е. ты делаешь запрос к бд, она выдает тебе ошибку и только потом ты ее анализируешь?😳

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

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

Выше код глянь, я уже это сделал

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

Зачем эта проверка нужна, если при добавлении записи всё равно можно словить исключение?

Второй абзац про это

Нет, второй абзац просто какая-то жалоба на жизнь, а не ответ на вопрос

Ну если у тебя друг аргументов нет, то хз как это обсуждать с тобой

Ты как поймешь, что выкинутое сообщение касается занятости юзернейма а не чего-то другого?

Ты не понимаешь вопрос, или игнорируешь неудобную для тебя часть про нарушение уникальности при записи?

Самый тупой вариант - в ошибке будет указан нарушенный constraint

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

С автосгенерированным нечитаемым именем

Да все равно, ловить исключение с бд и потом их парсить, это бред. Лучше сделать лишний запрос, чем парсить ошибки

Ну парсить текст да, бред. А если там есть строгий контракт, на который можно положиться, то почему бы и нет

да нет чувак. Алексей прав. этот твой лишний запрос до одного места. правильно делать, как он написал. единственное, что меня смущает, парсинг ошибок. если он стандартизирован, то все ок вообще

прикол в том, что если бд ловит ошибку, она прерывает транзу. а id Добавляется bи получается так id: 1,2,3,4,6,8,12,45,77

Я также парсил ошибки, пока один senior мне звиздюлей за это не дал

Это уже другой вопрос. Но я предпочитаю давать индексам читаемые имена

ну вот это плохо. с какого хрена там вообще речь идет о каком-то нарушенном constraint. по сути ты выплювываешь наружу детали реализации

Ну если таблицу полностью не лочить, то ты с предварительным запросом ты тоже не защищен от увеличения id

Как ты обрабатываешь ситуацию успешной проверки с последующей ошибкой при записи из-за того, что между проверкой и записью пролетел другой запрос, который сощдал запись с таким юзернеймом?

Наружу не надо отдавать это Речь о анализе ошибки бд на сервере

Не удалось создать пользователя. И все

очень информативно

Зато есть стандартизированный в пределах бд код ошибки

Если так, то хорошо

он показывает какой колонке какой констрейнт нарушен?

Кстати А если этого контракта нет? Предположим, прилетает строка с каким-то текстом Мой вопрос остаётся актуальным: что делать при возникновении этого исключения? То есть совершенно тупиковая ситуация: проверили, юзернейм свободен. Пытаемся писать, но юзернейм уже заняли

500 bad request

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

Тогда зачем делать проверки перед созданием, если клиенту всё равно тупо отдают bad request? Для ui Типа "иногда мы можем отдать читаемую ошибку, а иногда - ну сорян"? Да, так и есть

А тебе такой подход не кажется ужасным? Мало того что лишние запросы к бд, так и они в ряде случаев оказываются просто бессмысленны У вас такой код пройдёт ревью?

так чувак, много кто так и делает и не видет в этом ничего плохого. хуяк-хуяк и круды готовы

Ну не идеальный. Но парсить текстовую ошибку тоже такое себе. Если на это тесты написать, то уже получше

Почему бессмысленные и лишние, если есть смысл для ui? Те случаи, когда будет эксепшен из бд, редко будут происходить. ui просто попросит юзера повторить запрос и всё

а что такое круды?

это пост пут гет делит

А что в этом плохого?

ничего

это хорошо

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

В почти любом приложении есть стейт, который надо изменять и где-то хранить. Что в этом плохого?

Сложно оценить частоту таких событий. Это всё гадание Бессмысленные проверки потому что по хорошему в данном кейсе проверять надо результат добавления в базу, а не возможность добавления

А почему парсить текст ошибки плохо? Всегда ли парсинг строки это плохо? Если да, то какие методы сериализации допустимы?

Отстань

это непросто плохо, а хуево. как минимум, интуитивно это вызывает отторжение. а объективно, апнешь версию субд, и пиши свои парсеры снова

Это не плохо. Есть свои минусы, как и с вариантом с несколькими запросами к бд

От смены версии бд вряд ли изменится то, что в тексте будет код ошибки и название нарушенного constraint Есть ещё аргументы кроме этого?

> вряд ли вот тебе самый сильный аргумент

после круда я уже не ставил на тебя, но ты вывез

так мажорные версии не совместимы как минимум