думаю надо самому реализовать
через периодические задачи например

Если ты про то что тесты из коробки медленно работают с базой, то гугли nosetests и смотри у нему плагины и флаги у меня удавалось раза в 4 их быстрее проигрывать при tdd очень помогает, но если вы время от времени запускаете на Дженкинс, то думаю там не очень важно

не, не про тесты, про деплой уже

Храните кеш в редисе, чего его там греть

да в редисе то в редисе но если есть изменения в данных и нужно выкатить в продакшн с уже готовым кэшом что его пользователи не формировали а чтоб он уже был готов

лан, понял что нужно самому реализовать такой механизм

Народ, что скажете про Python Eve?

Хз, но судя по доке это что-то на основе фласка для реста, я бы смотрел в сторону фастапи

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

Куда пихать в Джанго политику конфиденциальности, чтоб ее видел гугл? (Требуется для рекламы в гугле)

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

Ну заводите свои товары в эластик серч или сфинкс. Потому что я слабо понимаю как тут можно кешеривать допустим у тебя есть 3 пары популярных кроссовок по скидке 44 размера набежали кусты распихали по баскетам, как ты собираешься кешировать наличие ?

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

Ну на сокрытие просто поставь удаление из кеша зачем его перечитывать?

У тебя одна позиция ушла, кеш тот же самый

Добрый день, прошу совета по "допиливанию" админки, вопрос скорее "хорошего тона"...
Есть масса моделей, News - просто пример для иллюстрации, для каждой прописан ModelAdmin (https://pastebin.com/UjAgmQN7) В пасте - только то, что касается вопроса, вроде, все лишнее убрал...
Изначально прописал наборы полей в свойствах класса (list_display, list_filter, list_editable)
Появилась необходимость разделить наборы полей для обычных пользователей и superuser.
Начал прописывать методы get_list_filter и прочие. Для большинства свойств есть аналогичные методы:
list_display - get_list_display и т.д. А вот для list_editable, как я понял, нет...
В результате наткнулся на то, что при указании поля в свойстве list_editable ругается на то, что поле отсутствует в list_display (его я перенес в метод)...
В итоге прописал list_display и в свойстве и в методе. То есть, то, что для всех, прописано в свойстве, а метод только изменяет его.
Вопрос - как правильнее поступать в таких случаях - переносить всю логику в метод или писать и свойство и метод?

Это как-то не проще через обычные группы и пермишены сделать?

А при чем здесь пермишшены? Речь про то, какие поля показывать в списке? Пользователи видят только своё, соответственно, незачем загромождать их экран, поскольку, например, в поле "издатель" они во всех строчках будут видеть СЕБЯ, а рут видит всех, ему - нужно. То же и с фильтрами.

Или я что-то не понимаю?

Всем привет, парни кто умеет вью джс деплоить с джанго?