Хороший формат видео, с новыми фишками. Будет здорово увидеть подобное и по другим популярным библиотекам(когда будут выходить обновления, конечно). Спасибо за ролик!
Спасибо за видео! Случайно попалось в рекомендациях. Было бы интересно всё таки в деталях узнать что же там нового в асинхронщине, так как сам вообще не вникал туда.
Подписывайтесь на канал и рекомендация перестанет быть случайной Если честно, мне кажется, что приминительно к джанге асинхронную часть можно будет рассматривать, когда уже будет все под это адаптировано + DRF/graphene
Наконец-то, это очень полезный функционал, который решает достаточно большое количество ситуаций. Переопределение save кстати не лучшая реализация, так как если в коде где-то используется update или bulk update то save не вызывается. А если все значения полей сохранять через save(), то получаются не очень оптимальные запросы к БД, что замедляет время работы.
Запросы к БД не изменяться, если вызывать до «супера», вы просто аттрибуты объекты переопределятся до сохранения в БД. Апдейты и балки (и создание и обновление), конечно, не отработают, потому что на уровне SQL-а отработает
добрый вечер, Николай! спасибо за разбор, недавно спросили про данный тип поля на собеседовании, а я знать не знал про такое нововведение - обогатился благодаря вам ;) подскажите, какую клавиатуру использовали в ролике? - очень приятно звучит
Нормальная штука, я где-то читал что переопределять save() не лучшая практика, лучше создать менеджер модели и инкапсулировать логику в нем. А почему в итоге поле с db_persist=False появилось в таблице? SQLite видимо не поддерживает такое поле?
Поддерживает, просто как и говорю в ролике оно рассчитывается при запросе к нему. Если посмотреть на структуру таблицы там будут оба поля, просто одно из них “generated”, в другое физически находится в БД. Смотря какую часть логики описываете, в менеджеры все-таки оперируем уровнем SQL-а
Добрый день! Один косяк обнаружил касаемо авторизации и ВЫХОДА пользователей. В Django 5.0 не работает стандартный класс LogoutView, когда в гкдыюзн вызываешь его через path('logout', LogoutView.as_view(), 'logout'). Вместо перевода на страницу с шаблоном в папке registration/logged.out выдается ошибка HTTP 405... Нигде еще не нашел решения. Похоже, что это баг.
Пошел проверить ради интереса, вот, что нашел: postimg.cc/dLwf27yZ Просто запретили метод get для этой вьюхи. Для 4 в ворнингах было (131 строка) - github.com/django/django/blob/stable/4.2.x/django/contrib/auth/views.py
Выскочит если отправить гет запрос, потому что теперь гет запросы не обрабатываются о чем и говорит 405 ошибка. Если открывать роут в браузере, т.е. открыть ссылку /logout, то браузер отправит как раз гет запрос и Джанго выдаст ошибку. Чтобы воспользоваться вьюхой надо отправить туда пост запрос, вот пример: docs.djangoproject.com/en/4.1/releases/4.1/#log-out-via-get
Если у тебя задача, сделать автоматически вычисляемое поле, то это удобный и простой способ сделать это, причем вычисляемым или физическим столбцом Можно костылить это на триггерах (create + update), но виртуального столбца все равно не добьешься
Какие ошибки? Я на своих проектах не замечал, вернее сказать действительно отваливался, но именно на новых версиях celery, зафризили версию пониже, больше проблем не наблюдаем
джанго уже свое отжил, даже нормальную асинхронщину завести не могут, его спасает только то, что много уже на нем написано и нужно этот калл как то поддерживать, учите фастапи господа
Согласен, конечно, что асинхрощину завести не могут, sync_to_async это костыли и не все middleware его поддерживают Но надо идти от задачи, надо понимать, что асинхронность даст прирост производительности, и что эта производительность нужнее (да и вообще требуется), чем скорость разработки Про учите фастапы - будьте осторжнее, тоже понимайте зачем. Fastapi 288 вакансий, 306 вакансий (hh на момент написания вакансии, мск)