Ещё раз спасибо за интересный материал!!! Авторизация очень интересна ))) Будет классно, если получится осветить и эту тему 🤝 Особенно ценна информация о том, как лучше делать в реальной работе (а не в учебных примерах), а как нет. Способов решить задачу много, но бывает сложно понять, какой лучше выбрать. Очень мало информации об этом. А инфоциган, которые по официальным докам нагенерили видео - много))) Было бы здорово, если бы Вам удалось больше такой информации добавлять в видео. Прямо вот не фундаментальные сравнения, а просто обогатить то, о чем рассказываете. Хотя, надеюсь, и в текущих видео "рафинированных" примеров немного, а больше Ваш личные рабочие решения и кейсы ))
Пожалуйста! Спасибо и вам Угу, авторизацию давно просят, я готовлю сценарий. Там точно больше одного и даже больше двух роликов получится, довольно объемная тема. Примеры все так или иначе связаны с реальной работой. Но, понятное дело, приходится их сильно упрощать, чтобы влезало в один ролик
Супер , спасибо за видео 👍В видео вроде это не упоминалось, но дополню что правило хорошего тона, удалять автоматически сгененрированные алембиком коменты из миграции, так в дальнейшем для себя будет понятно , что если коментов нет, то миграция проверялась глазами, если коменты остались, то видимо забыл взглянуть на нее)
Спасибо! Просто топ подача! Разжевал, проказал, все ясно понятно (кроме "*columns:" в UniqueConstraint( *columns:'tool_id', 'date_id', name = 'unique_tool_dste', )
Пожалуйста! Рад, что вам понравилось! "*columns:" добавляет PyCharm для понимания, что мы туда закидываем, этого текста в коде на самом деле нет. можно выключить подсказку в настройках
привет. сори, в ютубе сложно найти неотвеченные комменты, только сейчас вас заметил. для более быстрого общения пишите в телеграм чат (в описании тг канала ссылка) по коду: я бы попробовал сделать joinedload(User.addresses).order_by, а если так не прокатит, тогда на модели можно сортировку по умолчанию указать: docs.sqlalchemy.org/en/20/orm/relationship_api.html#sqlalchemy.orm.relationship.params.order_by , будет примерно так: `addresses = relationship("Address", backref="user", lazy="joined", order_by="Address.city")`, а в обратную сторону так: `... order_by="desc(Address.city)"`. да, прямо внутри строчки
Лучше поздно, чем никогда ) Тем более, что информации таким нюансам крайне мало. Спасибо за совет, попробую с моделью. С joinedload(User.addresses).order_by я уже пытался - не вышло@@SurenKhorenyan
16:30 это уже не метатаблица получается для связей, это что-то из разряда order_list. туда бы досыпать стоимость товара на время создания заказа, и м.б. доп инфу по скидкам
Сурен, спасибо за твою работу, много полезного для себя открываю из твоих видео. Недавно наткнулся на твою лекцию по json:api, довольно познавательно, но конечно хотельсь бы больше практических примеров построения, может что то подскажешь? Хотим попробовать организовать сервис по этой спеке в связке с fastapi. Есть ли какие то библиотеки для облегчения этой задачи?
Привет! Я сейчас веду активную разработку такой библиотеки, нам по работе было нужно github.com/mts-ai/FastAPI-JSONAPI Там есть подробная дока с примерами
@@SurenKhorenyan У меня как раз было открыто на соседней вкладке, даж не знал что твой проект. Тогда сразу репорт скину в первоисточник) При старте минимального примера на 3.12 ошибка: ImportError: cannot import name 'ModelMetaclass' from 'pydantic.main'
Добавление айдишника в связующей таблице, для создания связи многие ко многим, избыточно, т.к. уже есть составной первичный ключ, что может привести к аномалиям вставки\удаления\добавления. А так, всё классно!
Я пока не встречал ни одной ситуации, когда наличие выделенного первичного ключа помешало, зато встречал много ситуаций, когда отсутствие первичного ключа приводило к сложностям или даже доходило до полной остановки разработки до момента добавления отдельного первичного ключа. Так что придерживаюсь стороны добавления pk безусловно
Сурен , спасибо за ваш труд! Скажите, а почему не используете в relationship параметр "backref" вместо "back_populates" Ведь как я понимаю "backref" можно прописать только в одной из связываемых моделей и связь будет. Прописываете "back_populates" явно для читаемости кода? Или есть какие-то причины, особенности?
Привет! Пожалуйста! Мне больше нравится `back_populates`, так как это более явно, чем `backref`. Чтобы с двух сторон всё указать. Ведь явное лучше, чем неявное
Объяснения отличные, спасибо. Правда у меня, как у 1сника, небольшой ступор от заказов и связи многие ко многим. Когда делал пет-проект на джанге, то делал как принято в 1С: таблица заказов и связанную с ней 1 ко многим таблицу строк табличной части заказа, где указывался товар, количество, цена, сумма, и ссылка на заказ. Интересно, какой вариант предпочтительнее.
Пожалуйста! Ооо любопытно! Я бы обсудил детали. Приходите в чат в телеграм, показывайте как делали. Возможно, мне стоит такой вариант тоже показать в роликах 🙂 А может быть это примерно то же самое, просто отображение немного другое
Если когда-нибудь будет ролик по авторизации. Пожалуйста, затроньте тему как правильно обновлять jwt access token на основе refresh token. Все лепят по своему. Спасибо!
Наверное все это следовало делать через тесты с pytests, а так получилась какая-то оторванная от проекта лишняя сущность, которая по сути выполняет функцию тестирования с дописыванием кода самого проекта в процессе.
Нового для себя не услышал. Но тема раскрыта хорошо. Так держать! Спасибо Было бы здорово написать не сложное приложение, типа магазина, с использованием микросервисов на паттерне SAGA или 2pc
Пожалуйста! И вам спасибо Угу, тема интернет-магазина маячит, надо её раскрыть. А вот рассказывать про микросервисную архитектуру пока не думал. Спасибо за подскаку! Возьму на заметку
@@SurenKhorenyan я всегда в своих проектах добавляю этот параметр,чтобы доступ был к связанным сущностям. Вот, пытаюсь разобраться, считается ли это хорошей практикой или же лучше не лениться)
@@krushovice77 если я правильно понимаю работу lazy='selectin', то при каждом запросе сущности будут подтягиваться связанные сущности. зачастую это не нужно, так что я бы так не делал. Подргужать надо при необходимости
Когда лекторы говорят, что в MySQL или в MariaDB пoявилась поддержка JSON в ПОСЛЕДНИХ версиях, они спали десяток - полтора десятка последних лет? Этой фиче в указанных БД уже тыщу лет
Я думаю, тут дело привычки. Просто когда-то это было "вот недавно появилось", и так закрепилось в голове. У меня и аннотации типов в Python тоже совсем недавно появились 🙂 а это ж лет 8 назад было
Планируется ли в последующих видео рассмотрение авторизации с помощью гугл или фейсбук аккаунтов? В русскоязычном сегменте практически нет материалов по данной теме.
поле id в таблицах всегда в самом конце, т.к. в миграции имеет тип sa.PrimaryKeyConstraint('id') , а у sqlalchemy приоритет для типа sa.Column выше, потому сначала идут эти поля при создании таблицы, а почему оно не создает в миграции поле id как и остальные с типом sa.Column ? можно ли как-то поднять id вверх, что бы оно шло первым ?
Для таблицы это не имеет значения. Но если вам важен порядок отображения, то когда вы проверяете вручную миграцию, которая сгенерирована автоматически, то передвиньте добавление колонки в самое начало. Это надо сделать до применения миграции
@@SurenKhorenyan , я тоже сразу так подумал, что это поможет, но нет, здесь дело в приоритете orm, она всегда сначала создает колонки, которые в миграции обозначены - sa.Column , а потом уже остальное, а поле id не указано, как sa.Column, поэтому и добавляется после всех созданных колонок с sa.Column, здесь нужно решать как-то редактированием в модели, а вот как, пока не знаю ) если у вас получится - поделитесь, пжлста
@@user-fm1552 почему же? Берём вот эту строчку github.com/mahenzon/micro-shop/blob/7cee66248079513cbfc06b01d5a055954c92764a/alembic/versions/2023_09_03_1832-c9e562f01355_create_products_table.py#L28 И двигаем на место над созданием name. И всё
@@SurenKhorenyan , да, вы правы !!! моя невнимательность... я подымал вверх не ту колонку в миграционном файле ) спсб !!! но все же интересно, почему оно сразу не указывает колонку id первой, ведь в исходной модели сначала перечитывается базовая модель и по всей логики колонка id должна быть первой в миграционном файле
@@user-fm1552 отлично. хорошо, что удалось разобраться. так происходит потому, что в базовом классе объявлена колонка id, а остальные на текущей модели. По MRO (method resolution order) поиск свойств идёт сначала на текущем классе, потом на родителе, потом на родителе родителя.. поэтому до айди очередь доходит последней
