У меня в большинстве случаев работало без обратной связи, достаточно чтоб в одной стороне декоратор был Ну ща попробую сделать
ну можно и без этого тогда просто надо будет самому писать join запроc по userId к rolesId
В этом и проблема да, что по одному полю, нужно получить другое
так просто при селекте юзера сделайте джойн ролей по userId
и кстати зачем два many-to-one на одну и туже таблицу?
Да это прост написал, потому что точно не знаю как надо ему чтоб работал
когда пишите many-to-one на к примеру user то typeorm добавляет сама колонку userId то есть у каждого токена будет userId
Ну я бы хотел сделать чтоб вся логика связи была только в модели, без билдеров
ну тут я не уверен что без обратного декоратора это будет работать на подмазках typeorm и в квери билдере нет ничего плохого как и в чистых sql запросах так как рано или поздно выйдете за рамки орм так что привыйкайте сейчас
Тут больше вопрос концепции проекта, если начал в одном стиле, то лучше его и придерживаться, а не при первой возможности начать городить костыли
так это не костыли если хотети все в одном стиле то делайте строго по доке typeorm только в любом случаее при более сложном запросе орм вам уже не поможет)
Нет смысла городить сложные запросы где куча разом таблиц вызывается или какие-то вычисления, так как база была всегда узким горлышком в архитектуре проекта чтоб её перегружать, а так вся логика побита на куски по сервисам и всё под рукой (принцип единственной ответственности ), единственная проблема за все года у меня была только со связями в моделях
В доке мало гибкости в примерах, только методом тыка и опыта, поэтому и написал сюда
так причем тут сложные запросы если в результате sql будет такой же? просто без обратного декоратора на токены орм не понимает что джойнить
что работает?)
связь по userID
Обсуждают сегодня