может кто делал/находил пакет?

Это по-моему называется soft delete. Мне кажется там несложно и самому сделать на уровне репозиториев или добавив на декоратор Entity дефолтное условие выборки

не хотелось бы писать свою обертку, много логики

вопрос не про это

Всем привет! Столкнулся с таким понятием как n+1, можно же делать join чтобы избежать лишних запросов.  Не совсем понимаю в чем заключается проблема?

вообще, джойны дублируют строки в ответе, когда со стороны зависимой таблицы отношение *-ко-многим, что ломает работу limit/offset. но это решаемо вторым запросом с where … in.

проблема тут в том что в контексте первого запроса может не быть информации о том, какие связанные записи понадобятся в последствии. код, обрабатывающий полученные записи по одной, обращается к зависимостям, не зная что кроме текущей записи есть ещё N точно таких же и по ним нужно выбирать точно те же зависимости… вот тут и возникает N+1

особенно это становится заметно при работе с graphql когда каждая функция-резолвер видит очень узко только одну конкретную запись или даже одно поле одной записи… неудивительно что именно facebook предложил node-way решение задачи в виде пакета facebook/dataloader. каждый запрос выносится в nextTick и если цикл по записям отрабатывает синхронно, например с помощью forEach или map, то в nextTick скапливаются все N связанных запросов, которые dataloader объединяет в один… это не чисто graphql-решение, dataloader вполне применим и при работе с данными в rest api точно таким же образом…

либо надо в момент выполнения базового запроса смотреть в контекст и решать заранее какие зависимости подтягивать и активно пользоваться «жадной загрузкой»… typeorm реализует это либо на уровне entity – но параметр eager применяется ко всем выборкам без исключения… либо можно на уровне query builder заджойнить связи – под капотом там не обязательно будет именно join в запросе. typeorm сама знает когда можно джойнить а когда делать дополнительные запросы…

В разрезе gql можно каждый промис запроса складывать в котенкс. Но это работает только с простыми запросами

Так много говорят про графql, а я его вообще ни разу не использовал

Всем привет! Подскажите пожалуйста. Есть реляция между моделями, допустим OneToOne и у меня ОРМ создает(при sync: true) два ключа начинающихся REL_….  и IDX_….. и соответственно уникальные индексы с теми же именами. Но зачем? Зачем ОРМ дублиурет названия REL & IDX ???

я запарился вычищать это)

попробуй JoinColumn убрать

вроде когда убираешь не создает

Так JoinCOlumn обязателен для OneTo One?))

разве нет

нет

Мне походу придется тоже самое длать))

перейди на миграции

и сам создавай базу, выключи автосинк