связь вот так прописана

попробуй оставить только onDelete

Попробовал, тоже самое

В базе задай чтобы каскадом сносилось

Каскад он делет, это я так понял нужно при создании из ентити миграции или синхронизации с базой

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

когда идет настройка связей не на айдишное поле, нужно в Entity задавать foreignKey

Ребят, привет всем)

А подскажете, как сделать так чтобы этот код работал?

https://www.typescriptlang.org/play?#code/KYDwDg9gTgLgBDAnmYcDCEB2BnGUCuAxjNADwAqAfHALxwDecmwA7nABQB03AhlAObYAXHB6ZEAbQC6AShHk4AXwDcAKHVIUcAJKYw+GDwBGAG2CkA0nFAxgmACbY4uKAEtM-WnADkEMDFcsbG8AGjgFOjFEajp6VTg4CQAFOHc4Cyl5NRUNZFQAURA8HmJdfRhyPNIkmLgUmztHHT0DYzNSdwAzYChw6gB+OolyKTgRZgA3HrV1QhMebCcAMQgIVIBbMDN1uxgnMtbTc293cu9qOISEwiC8IhIodn1TV0JUlpgRen4RF3d+RQyeiKVQg1T2YBzPioTr4TDEQKYOCdEoPRAUaxFRr7D5tYCUdhzYToW4EYhkKhhU4GESFYqlD6VFAUShycIzFHkqCIdgrCBhb4ibzBQFAA

Кто-то делал имплементацию в духе AuthGuard, но со своей логикой, не связанной с авторизацией ?

То есть мне надо с опцией onCascade: "DELETE" пересоздать таблицу юзер?

Вот это особо не понял

У меня вопрос, но не по Несту, а больше по микросервисам самим.

Паттерн говорить дб для каждого сервиса. Окей.

Есть вот сервис каталога товаров.
Есть сервис выполненных заказов.
Есть естественно сервис юзеров.


Нормально ли сервис выполненных заказов будет дергать сервис юзеров и сервис каталога?  Тогда сервисы буду связанны? Это же анти паттерн.

Окей, можно использовать Реббит или Кафку и писать в базу заказов уникальных юзеров которые сделали заказ и уникалные товары которые были заказаны?

Или в реальности официальный паттерн не работает?

Привет! Это не опция, а свойство внешнего ключа. Миграцией пересоздай его

Уже вроде получилось

Всем спасибо

А, ну отлично

Немножко напутал
Это если у тебя допустим есть связь @ManyToOne в сущности и тебе нужно заджойнить с другой таблицы какое-то поле но не айдишник, то делается через @JoinColumn по айдишнику (под капотом я так понял это все равно через foreignKey делается)

Либо указать явно relations в опциях find

Паттерн где для одного сервиса - 1 база, распространён и имеет преимущество в виде возможности разнести нагрузку на базу, всегда одного ответственного за базу, но и имеет минусы:
- Необходимость управлять группой транзакций, если она затрагивает несколько сервисов
- Зависимости между микросервисами, которые сложно отследить.
- Не удобное использование данных для аналитики, так как они разнесены.

Для уменьшения связанности и управления транзакциями лучше всего использовать паттерн saga, где есть управляющий сервис, который оркестрирует микросервисы. Это может быть даже само API, но лучше делать отдельный сервис под конкретные доменные области, чтобы например управление заказами не замешивались с статьями для сайта.

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

Для обмена также рекомендую Kafka или RMQ (сам всегда использую RMQ). Главное увлекаясь микросервисами не сделать nano сервисы) Для этого советую почитать про DDD.