Основы Sequelize ORM
HTML-код
- Опубликовано: 21 окт 2024
- Основы работы с библиотекой Sequelize, определение моделей и задание связей между ними, ленивая и жадная загрузка, raw-запросы.
00:00 Что такое
00:49 Достоинства
01:44 Недостатки
02:20 Подключение
02:29 Модели
03:59 Имена создаваемых таблиц
04:40 Синхронизация моделей
06:00 Преимущества определения моделей как классы
06:11 Логирование
06:24 Создание экземпляра
07:09 Чтение из базы
09:38 Сортировка
12:15 Создание стандартных отношений
12:40 Отношение один к одному
14:10 Отношение один ко многим
15:00 Отношение многие ко многим
16:04 Использование отношений в запросах
17:41 Создание, обновление, удаление
20:02 Почему связи используются в паре
20:28 Raw (сырые) запросы
Без воды, все четко и понятно! Однозначно Топ!
очень мало русскоязычного контента о секвалайз. редкое и полезное видео
00:00 Что такое
00:49 Достоинства
01:44 Недостатки
02:20 Подключение
02:29 Модели
03:59 Имена создаваемых таблиц
04:40 Синхронизация моделей
06:00 Преимущества определения моделей как классы
06:11 Логирование
06:24 Создание экземпляра
07:09 Чтение из базы
09:38 Сортировка
12:15 Создание стандартных отношений
12:40 Отношение один к одному
14:10 Отношение один ко многим
15:00 Отношение многие ко многим
16:04 Использование отношений в запросах
17:41 Создание, обновление, удаление
20:02 Почему связи используются в паре
20:28 Raw (сырые) запросы
Спасибо за видео! Не надеялся найти что то подобное!
Спасибо огромное! Не сочти, пожалуйста, за грубость. Но было бы круто немного поработать с дикцией: поразборчивее и погромче.
Спасибо, это было очень полезно!
все отлично. к контенту вопросов нету, пофиксите пожалуйста эхо от микрофона пожалуйста
Отличное видео, спасибо
Thank you for presentation!
Не понял, вот изначально говорится, что belogsTo и hasOne являются методами для установление отношения 1 к 1 и отличаются лишь тем, куда будет помещён внешний ключ.
Потом идёт анализ таблиц foo и bar, мы делаем вывод что одна из таблиц может существовать без другой ( делаем вывод в какой их них должен находится внешний ключ ), но в итоге используем связку и 2ух методов
Foo.hasOne(Bar)
и
Bar.belongsTo(Foo),
так зачем мы используем 2 метода, для привязки 1ого внешнего ключа к одной из таблиц ?
11:20
то есть
при A.belongsTo(B) у нас ключ кладётся в A
при A.hasOne(B) - в B соответственно
то есть эта запись
Foo.hasOne(Bar)
Bar.belongsTo(Foo)
создаст внешний ключ в Foo, после чего создаст ещё один внешний ключ ?)
Я чёт вообще потерялся.
То есть я бы ещё понял, если б мы сделали
Foo.hasOne(Bar)
Foo.belongsTo(Bar)
чтобы иметь возможность обратиться к другой таблице из каждой таблицы
ну или выбрали один метод и создали лишь 1 ключ, а в таком подходе какой смысл?
Я как бы вижу результат использования методов в виде sql запроса, но он ( результат ) мне кажется каким-то абсолютно не последовательным. Описание методов и то, как они по итогу работают как-то не совпадают.
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.
Бро, объясняешь норм, но голос режет слух :/
Какой приятный голос 😊
Единственный Асмр который я слушаю 😂