-
Возможна ли рассинхронизация при кешировании данных в json/pickle полях? И как этого избежать или вообще не использовать такое кеширование.
Например если я хочу закешировать список просмотревших какой то объект в json поле (дополнительно к many-to-many таблице).
Спасибо. -
Вы говорите об этом кешировании как о чём-то конкретном... Возможно, я что-то упускаю, но я бы сказал, что как вы напишете такое поле, так оно и будет работать. В плане синхронности в том числе.
-
Прямо сейчас я имел в виду простейший вариант, например при просмотре объекта делать
object.viewed_by[user.id] = True;
Что то вроде этого. viewed_by - сериализованное поле. Т.е. никаких проверок на синхронизацию нет, просто в момент просмотра добавляется ключ. Значит в этом варианте вполне может произойти перезапись кеша? Как избежать перезаписи, или сделать совсем по другому? -
Тоже не понял, при чём тут сериализация. Вроде, всё упирается в синхронизацию данных между таблицами. Какое имеет значение формат этих данных-то?
В случае с viewed_by лучше сделать совсем подругому, конечно. Например, табличку вида (key, val), уникальную по этой паре. И туда добавлять всякие ('viewed_by', user_id).
Ваш вариант с сериализацией можно оформить в таком виде: object.user_id['viewed_by'] = True. Так перезапись всяких флагов или не мега-точных счётчиков не роляет. -
Таблица связи есть, кеширующее поле планировал только для того, чтобы показывать в списке объектов (иначе придется делать либо по запросу на строку либо +1 селект заранее и подготавливать массив во view). Подробнее, предположим есть
Article
User
и связь Many To Many юзеров к статьям.
У меня есть 2 варианта - сделать кеширующее поле, либо перед показом списка вытаскивать заранее все связи и сортировать во view. Чтобы при показе показывать всех юзеров относящихся к статье. Вопрос был не будет ли проблем с полем в наивной реализации. Т.е. поле это хеш, в момент действия туда заносится ключ user_id.
object.user_id['viewed_by'] = True.
Не понял как использовать вот это. -
У меня есть 2 варианта - сделать кеширующее поле, либо перед показом списка вытаскивать заранее все связи и сортировать во view.
А какой смысл в этих сложностях? select_related тяжело будет?
-
select_related не работает для many-to-many. в принципе подготовить данные во вьюхе нетрудно, просто чисто теоретически интересно будут ли проблемы с такой реализацией кеша (на будущее), чтобы знать что вообще не стоит думать об этом, либо узнать хороший способ как сделать.
-
Дык, это зависит от реализации синхронизации кэша, а не от места и способа хранения.
Как будет происходить синхронизация (по времени или по факту изменения данных)? Если второй вариант, будет ли вообще смысл в кэше? Насколько часто будут меняться данные по отношению к просмотрам закэшированного?
И имхо, лучше завязываться на стандартное кэширование Джанги, чем мудрить с полями:
- проще его отключать/включать будет
- если в файликах или памяти кэш, быстрее будет работать
- в бэкапы бд не будет попадать лишний там кэш
- и главное, можно сначала забить на это дело, вообще. Написать безо всякого кэша, а потом прикрутить по мере надобности. Может ещё алгоритмы поменяете пару раз и в конце концов кэш реализуется парой строчек в шаблоне :)
Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.