Відео

Foo.hasOne(Bar) Bar.belongsTo(Foo) Формально, Bar.belongsTo(Foo) можно и не вызывать, но тогда Bar не будет ничего знать о существовании Foo и нельзя будет пользоваться методами вида Bar.getFoo, либо указывать Foo в условиях поиска, например Bar.findOne({ include: Foo }) (при выполнении возникнет ошибка SequelizeEagerLoadingError: foo is not associated to bar!). При этом со стороны Foo все будет работать как положено. Указание связи у второй модели не приведет к созданию еще одного внешнего ключа, т.к. он уже есть. Допустим у нас есть модели Author и OfficialSite. Мы хотим сделать так, чтобы таблица авторов осталась неизменной, а дополнительная информация о сайте автора хранилась во второй таблице. Получится Author.hasOne(OfficialSite) т.е. у автора есть один сайт и при этом id автора указывается в таблице с сайтами, у второй модели вызовем OfficialSite.belongsTo(Author), что также скажет Sequelize о том что сайты относятся к авторам и хранят внешний ключ (id автора) у себя. Получается что оба метода говорят об одном и том же. Foo.hasOne(Bar) Foo.belongsTo(Bar) В таком случае у нас получилось бы что у автора есть сайт (может и не быть) и при этом автор сам является лишь дополнительной информацией о сайте, в таком случае выходит что автора тоже может не быть, что звучит не логично. Итого: указание связи со стороны второй модели может казаться излишним, т.к. говорит ровно о том же, что и связь со стороны первой модели, но эта связь нужна чтобы заработали механизмы Sequelize.

​ @ku3mi41 , Благодарю, в принципе понял, мы устанавливаем своего рода двустороннюю связь для того, чтобы извлекать из одной таблицу инфу о другой, жаль что дока сомнительная ( на которую я так понимаю и ссылается ролик в подавляющем большинстве моментов ). То есть ну там буквально написано, как действуют методы ( создают внешние ключи в таблицах ), а по итогу мы должны использовать 2 метода ( которые вроде как должны создать 2 внешних ключа в одной таблице в рамках одной связи) , просто чтобы связать таблицы, так скажем, с двух сторон. Я просто по итогу энивей не понимаю, как работает связка целиком, то есть опираясь на sql запросы, там опять же создаётся лишь один ключ ( 2 методами ). Как интересно в таком случае будет выглядеть sql запрос с учётом использования лишь 1ого )) Странно всё это, как итог связка просто запускает какие-то механизмы в sequilze и он, как я понимаю, когда надо в Foo получить информация о Bar, бежит в Bar, делает там запросы, пытаясь найти строки с foo_id и потом мы уже можем с помощью, например, include получить эту инфу в Foo. То есть почему эта возможность исключена по умолчанию ( опять же, если всё работает так, как я себе представляю ) не особо понятно. Признаться я уже несколько проектов написал на sequilize и в процессе самой работы проблем он часто не вызывал, не пытаешься вдумываться в моменты, пользуешься надстройкой, наслаждаешься жизнью, но вот эти связи и их магические методы меня заставляют чувствовать себя инвалидом. Это, наверное, одна из главных вещей из-за которых мне больше нравится та же Prisma, потому что там в плане связей всё куда нагляднее. Хотя, если sequilize - доминирующее коммерческое решение, наверное, это не просто так. Да и может я всё таки дико туплю и чего-то не понимаю. Опыт с нативным sql и с дб в принципе у меня не превышает пару месяцев, поэтому ,возможно, для меня это всё выглядит так, будто без 100 грамм тут разобраться, не будучи создателем ORM, довольно трудно. Ещё раз спасибо за ответ.

@@СергейЛукашевский-п2щ На самом деле весь ролик и представляет из себя чтение документации :))) возможно есть смысл записать какие-то более или менее осознанные примеры, разобрать основные примеры, но уже с каким-то мимнимальным проектом. По дефолту (без указания параметров) hasOne/hasMany/belongsTo выглядят так. будто это hasOne/hasMany создает внешний ключ, а belongsTo нужен только для "магии Sequelize", но на деле параметры внешнего ключа можно указывать с любой стороны и если указать имя ключа в belongsTo то он и будет его создавать. Не совсем понял на счет исключения по умолчанию. Почему не работают методы Bar если связь уже указана со стороны Foo? Если рассмотреть весь процесс во времени, то сначала инстанцируются обе модели, которые ничего не знаю друг о друге. Затем срабатывает метод hasOne/belongsTo в результате чего одна часть узнает о существовании другой. Тут можно предположить, что раз Foo узнал о Bar, то и знание Bar о Foo можно было бы осуществить под капотом. без необходимости в ручном вызове. Вероятно такое поведение продиктовано внутренней архитектурой Sequelize. Доминация sequelize объясняется скорее ее возрастом нежели особым качеством или удобством. Рано или поздно все равно приходится ходить в issues на github в поисках решения возникающей проблемы, и можно найти issue со своей проблемой, которая открыта скажем еще в 2018 и решения нет, т.к. архитектура проекта "против", решение будет либо излишне сложным, чего никто делать не хочет, либо эту архитектуру надо пересмотреть в некоторых аспектах, а этого авторы делать тоже не хотят, по итогу иногда приходится писать запросы вручную. Если посмотреть тренды npmtrends.com/@prisma/client-vs-sequelize-vs-typeorm то видно что Prisma растет быстрее чем sequelize/typeorm и уже скоро обгонит их по популярности, особенно учитывая что sequelize еще и проседает. Да грядет sequelize v.7 с поддержкой Typescript (бывший sequelize-typescript который перешел под крыло авторов оригинала) но будут ли решены принциальные проблемы которых становится только больше? Не уверен. В любом случае, не зависимо от ORM надо понимать что происходит под капотом, как строить SQL запросы, как они работают внутри базы данных, что происходит при их выполнении, как строится план запроса и чем это чревато. Как сказал Влад Тен "Будь базовым программистом". Ведь когда придет замена prisma внутри все также останется SQL.