D
обойтись без селери с редисом
Плохая идея
Size: a a a
2020 August 05
К-
Плохая идея
значит все таки с ними лучше?
я
rq хватит если потеря результатов некритична
я
Он не то что бы их теряет прям часто, но запись на диск у него асинхронна
D
значит все таки с ними лучше?
Что значит лучше или не лучше? Доставить пуш как минимум недёшево. Можно при желании добавить этот функционал прямо во вьюху, но это очень дурная затея. Что-то потеряется, а воркер uwsgi будет перегружен.
Все подобные операции нужно выносить куда-то подальше. Плюс я уверен, что не стоит слать уведомление на каждое событие x, например на лайк в инстаграме, а делать это стоит раз в n минут. Это тоже к celery
Все подобные операции нужно выносить куда-то подальше. Плюс я уверен, что не стоит слать уведомление на каждое событие x, например на лайк в инстаграме, а делать это стоит раз в n минут. Это тоже к celery
К-
ок, спасибо
AG
Это как раз в доке написано, только я все равно подтупливаю))) Можешь конкретный пример привести?
Только общий:
Есть склад, для изменения кол-ва объектов в нем, используется модель Транзакций.
Моделей (сущностей) которые могут влиять на кол-во на складе (создавать транзакции) может быть несколько.
Вот чтоб не добавлять на каждую сущность по полю (а кол-во сущностей может поменяться) и используется привязка через ContentType
Есть склад, для изменения кол-ва объектов в нем, используется модель Транзакций.
Моделей (сущностей) которые могут влиять на кол-во на складе (создавать транзакции) может быть несколько.
Вот чтоб не добавлять на каждую сущность по полю (а кол-во сущностей может поменяться) и используется привязка через ContentType
S
Только общий:
Есть склад, для изменения кол-ва объектов в нем, используется модель Транзакций.
Моделей (сущностей) которые могут влиять на кол-во на складе (создавать транзакции) может быть несколько.
Вот чтоб не добавлять на каждую сущность по полю (а кол-во сущностей может поменяться) и используется привязка через ContentType
Есть склад, для изменения кол-ва объектов в нем, используется модель Транзакций.
Моделей (сущностей) которые могут влиять на кол-во на складе (создавать транзакции) может быть несколько.
Вот чтоб не добавлять на каждую сущность по полю (а кол-во сущностей может поменяться) и используется привязка через ContentType
Все, понял. Спасибо!
AH
подскажите плиз, где обычно определяют view home пейджи, которая не относится ни к одному из приложений?
NC
подскажите плиз, где обычно определяют view home пейджи, которая не относится ни к одному из приложений?
мне кажется не часто ни к одному приложению не относится, т.е. и модели никакие не используются?. Обычно еще делают приложение со всякими дефолтными штуками - типа регистрация/логин/кастомный юзер, можно туда
AH
Nikolay Cherniy
мне кажется не часто ни к одному приложению не относится, т.е. и модели никакие не используются?. Обычно еще делают приложение со всякими дефолтными штуками - типа регистрация/логин/кастомный юзер, можно туда
чёт странно как-то
если я хочу сделать условно 2 приложения, которые имеют связь друг с другом, и, если я хочу разместить эту инфу на home page (типа home page проекта), в виде описания того, что есть на сайте, то мне нужно это засунуть в одно из приложений?
если я хочу сделать условно 2 приложения, которые имеют связь друг с другом, и, если я хочу разместить эту инфу на home page (типа home page проекта), в виде описания того, что есть на сайте, то мне нужно это засунуть в одно из приложений?
S
подскажите плиз, где обычно определяют view home пейджи, которая не относится ни к одному из приложений?
Я например создаю приложение front и туда все такое пихаю. Там обычно главная, контакты и обратная связь, документы еще бывает.
Если много таких страниц получается, можно папку создать views и там все вью на файлы разбить, типо:
Если много таких страниц получается, можно папку создать views и там все вью на файлы разбить, типо:
views
- contacts
- home
- feedBack
тд
ᅠᅠ
Здравствуйте, подскажите кроссплатформенные аналоги сельдерея
ᅠᅠ
Celery
NC
чёт странно как-то
если я хочу сделать условно 2 приложения, которые имеют связь друг с другом, и, если я хочу разместить эту инфу на home page (типа home page проекта), в виде описания того, что есть на сайте, то мне нужно это засунуть в одно из приложений?
если я хочу сделать условно 2 приложения, которые имеют связь друг с другом, и, если я хочу разместить эту инфу на home page (типа home page проекта), в виде описания того, что есть на сайте, то мне нужно это засунуть в одно из приложений?
а что тебя не устраивает?
AH
Я например создаю приложение front и туда все такое пихаю. Там обычно главная, контакты и обратная связь, документы еще бывает.
Если много таких страниц получается, можно папку создать views и там все вью на файлы разбить, типо:
Если много таких страниц получается, можно папку создать views и там все вью на файлы разбить, типо:
views
- contacts
- home
- feedBack
тд
спасибо, видимо так и сделаю
AH
Nikolay Cherniy
а что тебя не устраивает?
неявность, например
если у меня будет 10 приложений, в какое мне нужно лезть, чтоб найти home-page проекта?
если у меня будет 10 приложений, в какое мне нужно лезть, чтоб найти home-page проекта?
BB
ᅠ🐲 Aᅠ ᅠ Cᅠ ᅠ Iᅠ ᅠ D ᅠ ᅠ Rᅠ ᅠ Aᅠ ᅠ Ïᅠ ᅠ N 🐉
Здравствуйте, подскажите кроссплатформенные аналоги сельдерея
Попробуй dramatiq
NC
неявность, например
если у меня будет 10 приложений, в какое мне нужно лезть, чтоб найти home-page проекта?
если у меня будет 10 приложений, в какое мне нужно лезть, чтоб найти home-page проекта?
чтобы найти любой пэйдж проекта ты лезешь в корневой урл, просто сейчас редко когда первая страница оторвана от всего, обычно это основное приложение. И да называя приложение фронт можно людей запутать, будут там реакт искать)
S
Nikolay Cherniy
чтобы найти любой пэйдж проекта ты лезешь в корневой урл, просто сейчас редко когда первая страница оторвана от всего, обычно это основное приложение. И да называя приложение фронт можно людей запутать, будут там реакт искать)
реакт пусть в другом месте ищют я на VUE пилю 😁