Оптимизация Django. 8 - Redis и ручной кеш

[@hhhscvx]

видос топ наконец то нашел нормальное объяснение работы redis с джанго

[@SeniorPomidorDeveloper]

🔥спасибо

[@dimuha82]

Огромное спасибо за курс! Освещено много нюансов про которых даже в платных курсах нет инфы.

[@user-uw8hy1lc4p]

Ты просто гигант, Celery примеры просто бомба, особенно всякие побочные проблемы

[@TaimanSaidaliev]

Сеньор Помидорович Разработчик вы лучший!

[@SeniorPomidorDeveloper]

Спасибо!

[@BorisenkoV89]

Лайк не глядя 😎

[@Rulezzz3]

Отличные видео. Спасибо автору, продолжай снимать. Хейтеры всегда будут, и не снимут свои видео лучше вашего. Очень нравится такая подача материала

[@SeniorPomidorDeveloper]

Спасибо!

[@vadimnikadon7332]

Супер!!! Огромное спасибо

[@shaxzodnizamov9773]

Можно ещё delete метод модели Subscription переопределить и не юзать сигналы)

[@SeniorPomidorDeveloper]

точно!

[@user-uw8hy1lc4p]

receiver можно не коннектить так в ручную, а сделать автоматически, так же можно повесить на ресивер post_save, в нем проверять создался объект или нет и там уже запускать тачку. Там будет почище, чем в модели на save вешать

[@Chel1k7]

При такой реализации метода, при изменении тарифного плана в уже созданном объекте не будет меняться цена def save(self, *args, **kwargs): creating = not bool(self.id) result = super().save(*args, **kwargs) if creating: set_price.delay(self.id) return result

[@begula_chan]

Благодарю за еще одно прекрасное видео по интересной теме! У меня вопрос, почему вы не использовали django-debug-toolbar? С ним вроде намного удобнее контролировать SQL запросы

[@SeniorPomidorDeveloper]

С ним удобнее для веб страниц. Но если какие-то внутренние расчеты иди таски то он бесполезен

[@ibrahimoglu]

👍

[@jamjam3337]

спасибо!

[@akimovvadim4736]

Хорошие видосы у тебя. Я на четвертной Джанге пробую это все делать, пока не встретил больших проблем из-за различия версий.

[@SeniorPomidorDeveloper]

Супер. Это полезная инфа . Спасибо

[@pretcb]

Привет! Спасибо за этот урок, как раз хотел на практике пощупать cache! Очень все по делу. В методе save модели Subscription, если мы не создаем модель, а изменяем план или сервис, стоимость подписки price тоже должна пересчитываться как и total_amount, по-этому creating можно не проверять!? об этом уже писали в предыдущих комментах к урокам, но это мелочи:)

[@SeniorPomidorDeveloper]

Я бы как-раз не делал пересчет на любые изменения. Если мы уберем проверку creating, то при изменении полей, которые не влияют, тоже будет запускаться пересчет. По поводу изменений плана или сервиса. Я бы наверное запретил их изменять в принципе, на уровне приложения, а сделал бы только пересоздание подписки.Но я, почему-то этого не сделал. :)

[@shaxzodnizamov9773]

Момент с определением Subscription был создан или изменен не очень нравится, так как могут вызвать save передав id Subscription(id=1, ...). Я на одном из проектом натыкался на такое. Либо self._state.adding is True нужно использовать, либо сигналы )

[@SeniorPomidorDeveloper]

Очень плохая практика передавать id в не созданный объект. Надо делать так, как это делают , разрабатывая на Джанго. Я могу еще 10 способов придумать, «как делать не надо и все сломать». А зачем?

[@nikez600]

Спасибо большое за урок! Можете пояснить для меня, почему Вы предпочитаете не использовать сигналы в Django?

[@SeniorPomidorDeveloper]

Не вижу смысла. Точнее есть смысл там отлавливать удаление модели, но это редкий кейс. А по архитектуре, они работают неявно, (а явное лучше неявного) вызываются фреймворком где-то «под капотом», мы не видим в нашем коде когда и в каком количестве они вызываются . А если кода и их в коде много - это очень не удобно. Если просто вызывать тот же код из save() это хотя бы будет видно. А плюсов нет, они также работают синхронно, также нагружают систему, это просто архитектурное решение и по-моему не самое удачное

[@nikez600]

@@SeniorPomidorDeveloper Еще они хорошо изолируют приложения и да, дебажить их неприятно. С Вашими аргументами согласен, лучше явное. В моем случае с сигналами приходилось комментировать в моделях на какие сигналы они завязаны

[@timofey-0307]

Привет! Вот вы сказали, что не большой любитель django сигналов, но почему? Они чем-то плохие, или вам просто не нравится? Это я спросил, чтобы понимать, стоит ли их использовать в дальнейшей разработке или лучше найти другой метод.

[@SeniorPomidorDeveloper]

По тому что они не очевидные. Вот я сохранил модель , и где-то какие-то сигналы запустились. Если проект большой то увидеть это в когде не всегда просто. Их надо по коду искать, и более того, о них надо всегда помнить. Если я напишу код в методе save() то я всегда буду его видеть , я понимаю что он запуститься на сохранении модели. Но вот сигнал на delete штука полезная, его сложно чем-то заменить

[@timofey-0307]

@@SeniorPomidorDeveloper спасибо за ответ и за курс!

[@1978rembo]

Здравствуйте. Не могу найти ваш профиль в GitHub.

[@SeniorPomidorDeveloper]

github.com/chepe4pi/service_app/tree/day-10

[@Ch1ck3nWTF]

Получается, что сигналы - это по сути триггеры, но на уровне питона?

[@SeniorPomidorDeveloper]

Ну приблизительно.

[@Ch1ck3nWTF]

@@SeniorPomidorDeveloper Спасибо ответы и курс в целом, очень толковая инфа в море хеллоуворлд'ов)

[@storlay]

При попытке добавления нового сервиса на 16:36 ошибка 'Service' instance needs to have a primary key value before this relationship can be used. Проблема в переопределении метода save, не могу понять как решить её

[@SeniorPomidorDeveloper]

Не понятно. Тут надо лог целиком смотреть, в нем должно быть написано

[@SeniorPomidorDeveloper]

Я имею ввиду что надо смотреть трейсбек ошибки

[@storlay]

@@SeniorPomidorDeveloper курс бесценный я считаю, только благодаря нему смог разобраться в Celery, глубже вник в docker-compose, и узнал много нового об оптимизации Спасибо за курс) Тоже в БА кстати

[@SeniorPomidorDeveloper]

Спасибо за отзыв! БА - супер! Где живешь?

[@storlay]

@@SeniorPomidorDeveloper в Палермо, Las cañitas, рядом с ипподромом. А ты где остановился?

[@user-gk8ex9qs8h]

Забавно что в предыдущих уроках ты писал о том, что не любишь сигналы, а тут используешь. В целом не нужно было пихать в +100500 сейвов очистку кэша, можно было бы это сделать в одном сигнале перечислив модели. @receiver(pre_save, sender=Model1) @receiver(pre_save, sender=Model2) @receiver(pre_save, sender=Model3) def reset_cache(sender, instance, **kwargs): pass Также файлик никогда никто не называет recievers в любом проекте это файл signals. Настройку сигналов делают в apps в функции ready() from django.apps import AppConfig class BillingConfig(AppConfig): name = 'project.test' def ready(self): from project.test import signals # NOQA Вообщем посмотрел 8 уроков, за такой код и такую оптимизацию меня бы уволили) Отписка не глядя!

[@SeniorPomidorDeveloper]

Не глядя уже не получится)

[@dodokwak]

Все будут только рады, если вы покажите лучше вариант.

[@user-jd4rl7im6d]

Почему pre_save а не post_save? Вдруг сохранить модель не получится, потеряем кэш просто так.

[@SeniorPomidorDeveloper]

Ничего нет плохого в том чтобы потерять кеш просто так.

[@SeniorPomidorDeveloper]

Post save пока отрабатывает может какое-то время выдаваться неактуальный кеш, а это хуже

[@akashpmani]

Hello Iam from india i didnt understand a word you said but i learned few things from this video thanks for that , can you share your github or source code of this

[@SeniorPomidorDeveloper]

Namaste! This is the source code github.com/chepe4pi/service_app I love India, I have visited your country 4 times. What state are you from?

[@sayhellotoroy]

охереть.. здесь и тут, такой импорт. Хорошо бы называть где это "здесь" и какой именно импорт продиктовать.

[@SeniorPomidorDeveloper]

Да я сам охренел, когда переслушал 😁