receiver можно не коннектить так в ручную, а сделать автоматически, так же можно повесить на ресивер post_save, в нем проверять создался объект или нет и там уже запускать тачку. Там будет почище, чем в модели на save вешать
При такой реализации метода, при изменении тарифного плана в уже созданном объекте не будет меняться цена def save(self, *args, **kwargs): creating = not bool(self.id) result = super().save(*args, **kwargs) if creating: set_price.delay(self.id) return result
Благодарю за еще одно прекрасное видео по интересной теме! У меня вопрос, почему вы не использовали django-debug-toolbar? С ним вроде намного удобнее контролировать SQL запросы
Момент с определением Subscription был создан или изменен не очень нравится, так как могут вызвать save передав id Subscription(id=1, ...). Я на одном из проектом натыкался на такое. Либо self._state.adding is True нужно использовать, либо сигналы )
Очень плохая практика передавать id в не созданный объект. Надо делать так, как это делают , разрабатывая на Джанго. Я могу еще 10 способов придумать, «как делать не надо и все сломать». А зачем?
Привет! Спасибо за этот урок, как раз хотел на практике пощупать cache! Очень все по делу. В методе save модели Subscription, если мы не создаем модель, а изменяем план или сервис, стоимость подписки price тоже должна пересчитываться как и total_amount, по-этому creating можно не проверять!? об этом уже писали в предыдущих комментах к урокам, но это мелочи:)
Я бы как-раз не делал пересчет на любые изменения. Если мы уберем проверку creating, то при изменении полей, которые не влияют, тоже будет запускаться пересчет. По поводу изменений плана или сервиса. Я бы наверное запретил их изменять в принципе, на уровне приложения, а сделал бы только пересоздание подписки.Но я, почему-то этого не сделал. :)
Не вижу смысла. Точнее есть смысл там отлавливать удаление модели, но это редкий кейс. А по архитектуре, они работают неявно, (а явное лучше неявного) вызываются фреймворком где-то «под капотом», мы не видим в нашем коде когда и в каком количестве они вызываются . А если кода и их в коде много - это очень не удобно. Если просто вызывать тот же код из save() это хотя бы будет видно. А плюсов нет, они также работают синхронно, также нагружают систему, это просто архитектурное решение и по-моему не самое удачное
@@SeniorPomidorDeveloper Еще они хорошо изолируют приложения и да, дебажить их неприятно. С Вашими аргументами согласен, лучше явное. В моем случае с сигналами приходилось комментировать в моделях на какие сигналы они завязаны
Забавно что в предыдущих уроках ты писал о том, что не любишь сигналы, а тут используешь. В целом не нужно было пихать в +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 уроков, за такой код и такую оптимизацию меня бы уволили) Отписка не глядя!
Привет! Вот вы сказали, что не большой любитель django сигналов, но почему? Они чем-то плохие, или вам просто не нравится? Это я спросил, чтобы понимать, стоит ли их использовать в дальнейшей разработке или лучше найти другой метод.
По тому что они не очевидные. Вот я сохранил модель , и где-то какие-то сигналы запустились. Если проект большой то увидеть это в когде не всегда просто. Их надо по коду искать, и более того, о них надо всегда помнить. Если я напишу код в методе save() то я всегда буду его видеть , я понимаю что он запуститься на сохранении модели. Но вот сигнал на delete штука полезная, его сложно чем-то заменить
При попытке добавления нового сервиса на 16:36 ошибка 'Service' instance needs to have a primary key value before this relationship can be used. Проблема в переопределении метода save, не могу понять как решить её
@@SeniorPomidorDeveloper курс бесценный я считаю, только благодаря нему смог разобраться в Celery, глубже вник в docker-compose, и узнал много нового об оптимизации Спасибо за курс) Тоже в БА кстати
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
Огромное спасибо за курс! Освещено много нюансов про которых даже в платных курсах нет инфы.
Ты просто гигант, Celery примеры просто бомба, особенно всякие побочные проблемы
видос топ
наконец то нашел нормальное объяснение работы redis с джанго
🔥спасибо
Отличные видео. Спасибо автору, продолжай снимать. Хейтеры всегда будут, и не снимут свои видео лучше вашего. Очень нравится такая подача материала
Спасибо!
Сеньор Помидорович Разработчик вы лучший!
Спасибо!
Лайк не глядя 😎
receiver можно не коннектить так в ручную, а сделать автоматически, так же можно повесить на ресивер post_save, в нем проверять создался объект или нет и там уже запускать тачку. Там будет почище, чем в модели на save вешать
Можно ещё delete метод модели Subscription переопределить и не юзать сигналы)
точно!
Супер!!! Огромное спасибо
Хорошие видосы у тебя. Я на четвертной Джанге пробую это все делать, пока не встретил больших проблем из-за различия версий.
Супер. Это полезная инфа . Спасибо
При такой реализации метода, при изменении тарифного плана в уже созданном объекте не будет меняться цена
def save(self, *args, **kwargs):
creating = not bool(self.id)
result = super().save(*args, **kwargs)
if creating:
set_price.delay(self.id)
return result
Благодарю за еще одно прекрасное видео по интересной теме!
У меня вопрос, почему вы не использовали django-debug-toolbar? С ним вроде намного удобнее контролировать SQL запросы
С ним удобнее для веб страниц. Но если какие-то внутренние расчеты иди таски то он бесполезен
Момент с определением Subscription был создан или изменен не очень нравится, так как могут вызвать save передав id Subscription(id=1, ...). Я на одном из проектом натыкался на такое. Либо self._state.adding is True нужно использовать, либо сигналы )
Очень плохая практика передавать id в не созданный объект. Надо делать так, как это делают , разрабатывая на Джанго.
Я могу еще 10 способов придумать, «как делать не надо и все сломать». А зачем?
Привет! Спасибо за этот урок, как раз хотел на практике пощупать cache! Очень все по делу. В методе save модели Subscription, если мы не создаем модель, а изменяем план или сервис, стоимость подписки price тоже должна пересчитываться как и total_amount, по-этому creating можно не проверять!? об этом уже писали в предыдущих комментах к урокам, но это мелочи:)
Я бы как-раз не делал пересчет на любые изменения. Если мы уберем проверку creating, то при изменении полей, которые не влияют, тоже будет запускаться пересчет.
По поводу изменений плана или сервиса. Я бы наверное запретил их изменять в принципе, на уровне приложения, а сделал бы только пересоздание подписки.Но я, почему-то этого не сделал. :)
👍
спасибо!
Спасибо большое за урок! Можете пояснить для меня, почему Вы предпочитаете не использовать сигналы в Django?
Не вижу смысла. Точнее есть смысл там отлавливать удаление модели, но это редкий кейс. А по архитектуре, они работают неявно, (а явное лучше неявного) вызываются фреймворком где-то «под капотом», мы не видим в нашем коде когда и в каком количестве они вызываются . А если кода и их в коде много - это очень не удобно. Если просто вызывать тот же код из save() это хотя бы будет видно. А плюсов нет, они также работают синхронно, также нагружают систему, это просто архитектурное решение и по-моему не самое удачное
@@SeniorPomidorDeveloper Еще они хорошо изолируют приложения и да, дебажить их неприятно. С Вашими аргументами согласен, лучше явное. В моем случае с сигналами приходилось комментировать в моделях на какие сигналы они завязаны
Забавно что в предыдущих уроках ты писал о том, что не любишь сигналы, а тут используешь.
В целом не нужно было пихать в +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 уроков, за такой код и такую оптимизацию меня бы уволили) Отписка не глядя!
Не глядя уже не получится)
Все будут только рады, если вы покажите лучше вариант.
Почему pre_save а не post_save? Вдруг сохранить модель не получится, потеряем кэш просто так.
Ничего нет плохого в том чтобы потерять кеш просто так.
Post save пока отрабатывает может какое-то время выдаваться неактуальный кеш, а это хуже
Привет! Вот вы сказали, что не большой любитель django сигналов, но почему? Они чем-то плохие, или вам просто не нравится? Это я спросил, чтобы понимать, стоит ли их использовать в дальнейшей разработке или лучше найти другой метод.
По тому что они не очевидные. Вот я сохранил модель , и где-то какие-то сигналы запустились. Если проект большой то увидеть это в когде не всегда просто. Их надо по коду искать, и более того, о них надо всегда помнить. Если я напишу код в методе save() то я всегда буду его видеть , я понимаю что он запуститься на сохранении модели.
Но вот сигнал на delete штука полезная, его сложно чем-то заменить
@@SeniorPomidorDeveloper спасибо за ответ и за курс!
Получается, что сигналы - это по сути триггеры, но на уровне питона?
Ну приблизительно.
@@SeniorPomidorDeveloper Спасибо ответы и курс в целом, очень толковая инфа в море хеллоуворлд'ов)
Здравствуйте. Не могу найти ваш профиль в GitHub.
github.com/chepe4pi/service_app/tree/day-10
При попытке добавления нового сервиса на 16:36 ошибка 'Service' instance needs to have a primary key value before this relationship can be used.
Проблема в переопределении метода save, не могу понять как решить её
Не понятно. Тут надо лог целиком смотреть, в нем должно быть написано
Я имею ввиду что надо смотреть трейсбек ошибки
@@SeniorPomidorDeveloper курс бесценный я считаю, только благодаря нему смог разобраться в Celery, глубже вник в docker-compose, и узнал много нового об оптимизации
Спасибо за курс)
Тоже в БА кстати
Спасибо за отзыв! БА - супер! Где живешь?
@@SeniorPomidorDeveloper в Палермо, Las cañitas, рядом с ипподромом. А ты где остановился?
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
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?
охереть.. здесь и тут, такой импорт. Хорошо бы называть где это "здесь" и какой именно импорт продиктовать.
Да я сам охренел, когда переслушал 😁