Форум → Программирование → PHP для идиотов → Позакешировать виджеты, которые появляются в случайном порядке
Позакешировать виджеты, которые появляются в случайном порядке
Страницы: ← Следующая страница →
-
Есть всеразличные блоки/виджеты (советы), которые появляются от некоторых условий, связанных с пользователем. Сейчас таких около 8, дальше будет больше. У советов есть метод isAvailible(), в котором проверяем доступность этого совета, формируем список доступных и выгребаем случайный
Например
1. Если пользователь посещал какие-то мероприятия 2 дня назад - выбираем случайное из них и предлагаем загрузить к нему фотки
2. Выгребаем людей, с которыми он когда-либо посещал какие-то мероприятия, из них берем случайного и предлагаем добавить его в друзья
3. Выбираем группы, в которых состоит пользователь, из них берем случайную и предлагаем ее попиарить
4. Случайное непрочитанное сообщение
и тд.
Как это дело можно закешировать? Слишком много всяких случайных выборок, не на что завязаться -
20 марта 2012 г. 18:06, спустя 6 минут 50 секунд
кеширование же для лохов. хули ты как бот тоСапожник без сапог -
20 марта 2012 г. 18:15, спустя 8 минут 53 секунды
ну да, но здесь слишком уж дохуя запросов появляется. Пусть они и относительно легкиеСпустя 18 сек.и их будет все больше и больше -
20 марта 2012 г. 18:34, спустя 18 минут 24 секунды
не кэшировать. ваш кэпСпустя 56 сек.ну тут кэширование не в теме, имхо -
-
20 марта 2012 г. 18:37, спустя 1 минуту 35 секунд
тормоза на подходе
не пускай их к своему мозгу и всеСапожник без сапог -
20 марта 2012 г. 18:46, спустя 8 минут 57 секунд
я ж откуда знаю, как быть :DСпустя 108 сек.первая глупая мысль, что приходит в голову (в стиле костыля мысль, кстати) - в промежуточные таблицы херачить что-то а ля юзер-виджет-доступные_айдишникиСпустя 41 сек.но тогда проблема с обновлением всей этой хрени -
20 марта 2012 г. 18:50, спустя 4 минуты 4 секунды
но тогда проблема с обновлением всей этой хрени
воот, это немногим лучше html caching
такое есть, например мы обновляем кросс-таблицу пользователь-возможные друзья и при добавлении друга триггерим событие, слушатель которого удаляет из нее строкуСпустя 21 сек.такое есть
просто наверно нужно как-то глубже развивать эту тему -
20 марта 2012 г. 18:55, спустя 4 минуты 28 секунд
Абырвалг, а почему мы на мускуле? :-)Сапожник без сапог -
20 марта 2012 г. 19:18, спустя 22 минуты 51 секунду
Абырвалг, а почему мы на мускуле? :-)
угу, тоже как-то непонятно, учитывая, что это типа соц сеть -
20 марта 2012 г. 19:20, спустя 2 минуты 5 секунд
хм… вопрос странно звучит: "Как сделать статическим то, что обязательно должно быть динамическим?"
и вообще, кеш - это то. что должно какое-то время хранится без постоянного обновления. А у тебя это самое время играет одну из главных ролей в условиях выбора что отображать.
Но в целом как вариант: дергаешь один раз сразу пару-тройку вариантов наборов для конкретного юзера и хранишь это все дело какое-то небольшое время, отдавая юзеру рандомно один из вариантов. И так до того момента, пока либо юзер не отреагирует на эти блоки (прочитает непрочитанный месседж, добавит фотки на какое-то событие и т.д.) либо же до истечению времени жизни твоего "кеша виджетов". -
20 марта 2012 г. 20:06, спустя 46 минут 15 секунд
А вот если допустим ORM генерировала бы какие-то *.sql файлики с экспрешионами/подстановками, а программист мог бы их редактировать под себя, делая работу ORM более тонкой. Однако в таком случае лучшее решение было бы чисто на основе ручной компиляции. Что-то подобное я использую у себя в миграциях в бетман.пхп, там из миграционных сущностей создаются .sql файлы и их можно руками отредактировать перед самой миграцией -
20 марта 2012 г. 20:09, спустя 3 минуты 15 секунд
Ivan, аляdjango_manage.py sqlall auth"
BEGIN;
CREATE TABLE "auth_permission" (
"id" integer NOT NULL PRIMARY KEY,
"name" varchar(50) NOT NULL,
"content_type_id" integer NOT NULL REFERENCES "django_content_type" ("id"),
"codename" varchar(100) NOT NULL,
UNIQUE ("content_type_id", "codename")
)
;
CREATE TABLE "auth_group_permissions" (
"id" integer NOT NULL PRIMARY KEY,
"group_id" integer NOT NULL,
"permission_id" integer NOT NULL REFERENCES "auth_permission" ("id"),
UNIQUE ("group_id", "permission_id")
)
;
CREATE TABLE "auth_group" (
"id" integer NOT NULL PRIMARY KEY,
"name" varchar(80) NOT NULL UNIQUE
)
;
CREATE TABLE "auth_user_user_permissions" (
"id" integer NOT NULL PRIMARY KEY,
"user_id" integer NOT NULL,
"permission_id" integer NOT NULL REFERENCES "auth_permission" ("id"),
UNIQUE ("user_id", "permission_id")
)
;
CREATE TABLE "auth_user_groups" (
"id" integer NOT NULL PRIMARY KEY,
"user_id" integer NOT NULL,
"group_id" integer NOT NULL REFERENCES "auth_group" ("id"),
UNIQUE ("user_id", "group_id")
)
;
CREATE TABLE "auth_user" (
"id" integer NOT NULL PRIMARY KEY,
"username" varchar(30) NOT NULL UNIQUE,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(30) NOT NULL,
"email" varchar(75) NOT NULL,
"password" varchar(128) NOT NULL,
"is_staff" bool NOT NULL,
"is_active" bool NOT NULL,
"is_superuser" bool NOT NULL,
"last_login" datetime NOT NULL,
"date_joined" datetime NOT NULL
)
;
CREATE INDEX "auth_permission_e4470c6e" ON "auth_permission" ("content_type_id");
COMMIT;
? :PСапожник без сапог -
20 марта 2012 г. 20:18, спустя 8 минут 58 секунд
Ты про миграции? У меня они пока-что выглядят как-то так и кешируются как-то так -
Страницы: ← Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!