а декоратор @Entity() нигде не пропущен? 🙂

ещё может entity не зарегистрирована в конфиге typeorm

Мы только что поняли, что весь день не видили то, что файл назывался discipline.enitity.ts

Eni tity Кхххх

И этот i не было видно даже. И мы очень долго думали "Почему так?"
Вот как-то так. Да.

бывает 🙂 советую поставь расширение спеллчекер, есть и для вскоде и для джетбрейнс – такие опечатки ловит и подчёркивает сразу же… 🙂

Ох, да. Уже поставил. Спасибо!

Привет! Подскажите, save умеет в update, если такая сущность есть, но как ей указать, по какому параметру находить "такую-же"?

он смотрит на PrimaryColumn

А как-то варьировать это нельзя?

А зачем? РК уникален и не null - это идеальный вариант.

Потому что иначе невозможно сделать "upsert": если пришли новые данные, у которых очевидно нет PK - придётся лезть за ним в базу, а если я уже слазил в базу, то двойственное поведение save/update мне и не к чему получается.

так save так и работает – открывает транзакцию, делает селект по PK, если что-то пришло – update, если нет – insert. транзакция закрывается, энтити сохраняется…

если он делает инсерт, то после него в случае mysql опять селект – чтобы получить все generated поля, если PK – generated, за ним лазить не надо, его можно бесплатно получить на инсерте через last insert id. postgres умеет returning – он умеет generated-поля получать сразу на insert.

если использовать в качестве PK uuid-ы (или аналоги типа nanoid, shortid), а не инкрементные айдишники – их можно генерировать сразу на клиенте… если при этом сразу же на клиенте делать и всякие createdAt, то generated-полей не будет, и селект после insert typeorm делать не будет…

Так это под капотом происходит. С созданием uuid не вариант так сделать, если я не знаю, есть ли уже такое "не-PK" поле в базе, потому у меня сейчас для этих целей самописный велосипед isSuchEntityInDB ? update : create ; Кейс простой - часть методов приложения не должны создавать сущности, если они уже есть в базе, при чём constraint уникальности не применим. Мой вопрос не про оптимизацию исполнения, а больше про "user experience" от библиотеки.😀 Я с монги перекатился, там {upsert: true} и всё.

ну я не вижу особой проблемы в том чтобы имитировать поведение орм-ки в своём коде каким-то особым способом… и это не велосипед, а самое обычное расширение стандартного функционала своей логикой… завёл кастомный репозиторий для сущности и пишешь в нём всё тебе нужно… вызывающему коду какая разница что вызывать – save() или saveLikeCoolKids() 🙂

Триггером можно выкинуть ошибку если запись по определённым параметрам есть

Например есть уже "Иванов" а ты суешь "ивонов", и так как скорее всего была опечатка то уникальность по этому полю не поможет, но функция приблеженного сравнения в тригере сможет найти и ругнутся

Добрый день; Такой вариант ведь валиден для поиска по полям сущности института? Или лучше сделать отдельное dto. (вместо DeepPartial)