сложная логика

да

или сложная реализация)

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

и второй таблицы вообще не было

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

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

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

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

а эти данные, которые я описал, они нужно только что бы установить связь many to one

оверкил

а что можно еще сделать?

ну во-первых, насколько я понял, автор уже справился с задачей, а во-вторых, «в тайморм почти ничего не работает» – это неправда, в нём как раз работает чуть менее чем всё, а задача «выбрать по many-to-many записи у которых нет связи» решается элементарно благодаря свойствам LEFT JOIN – когда связанных записей нет он джойнит на вектор из NULL-ов, поэтому достаточно добавить в query builder left join на связанную таблицу (а для many-to-many это будет пивот-таблица связи), и в where добавить условие что pivot_table.otherEntityId IS NULL.

то есть задача решается исключительно на уровне знания SQL, а искать решение где-то в апи ORM-ки и, не найдя, жаловаться  что «в тайморм почти ничего не работает» – это как раз то про что я и написал «большое полотно»…

TypeORM как раз отличная штука. в ней многие вещи сделаны очень просто и логично, есть несколько уровней абстракции, которые можно выбирать в зависимости от того что нужно – на самом верхнем есть Repository.findXXX() которые минимальными усилиями закрывают 80% потребностей, чуть пониже есть query builder который покрывает ещё 19% и оставшийся 1% решается сырым SQL на EntityManager.query()

в TypeORM есть хитрые моменты – первый это зачем он делает отдельно SELECT DISTINCT перед основным запросом (ответ – для правильной работы LIMIT в условиях выборках с джойнами на релейшены), и второй – чем отличаются разные версии innerJoinXXX и leftJoinXXX в query builder (ответ – тем куда они складывают результат, кладут одну запись или несколько или вообще выбрасывают их, но можно использовать WHERE). всё это решается заглядыванием в исходники…

Добрый день.
Такая незадача возникла, хочу проставить в поле окончания действия сертификата по умолчанию 'NOW() + interval '1 year',  но из-за того что typeorm использует экранирование, ловлю ерроры при синхронизации.
Может кто сталкивался

Примерно вот так выглядит решение
  default: () => "CURRENT_TIMESTAMP + interval '1 year'"
Возможно кому-то пригодиться

Может в миграции для колонки default поставить ?

Так это и есть свойство декоратора @COLUMN

ребят, а можно в typeorm сделать тип такого апдета?

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

С фильтрами точно можно, а вот с джойнами хз