Это относится к тому, если бы мне нужно было искать по статьям, а мне в результате необходимо переадресовать пользователя на внутреннюю страницу сайта, которая будет отвечать на этот вопрос. С учётом того, что городом может быть много и к тому же они могут меняться динамически, этот вариант совсем не подходит.
RU: изначально у меня и было сделано подобным образом, но позже, когда число запросов перевалило некоторую отметку, таблица, хранящая время, стала безумно тормозить и блокировать работу сайта. Потому и появился вопрос.
Ок, пока начну с перевода этого вопроса в Issue на GitHub, но боюсь, что моих навыков разработки не хватит для вмешательства в движок Yii 2 )) Впрочем, я в любом случае попробую.
Я докопался до метода populateRelation в ActiveRelationTrait, но переопределить его несколько проблематично в том плане, что это трейт (впрочем это ещё решаемо) + метод довольно объёмный.
Вы ведь являетесь core-разработчиком Yii2, можете что-то предложить?
Александр Макаров, да, я читал документацию и знаю про встроенное тэгирование. Меня больше волнует именно момент запроса релейшенов. Т.е. у каждого User есть Skin и этот скин уже есть в кэше (предположим). При запросе списка юзеров со скинами, в базу всё равно уйдёт запрос SELECT * FROM skins WHERE id IN ... . Меня же интересует, как можно наиболее "красиво" влезть в логику ActiveRecord, чтобы там из отобранных id сразу отбирать сущности в кэше и добирать только недостающие.
При обновлении используется UPDATE, иных индексов, кроме как первичного у таблицы нету, да и первичный не меняется (он создаётся синхронно с созданием записи пользователя), обновляется только поле timestamp и иногда action (описывал в самом вопросе).
На счёт джоинов разных типов таблиц вроде как читал на хабре, что временами такая связка даёт даже больший прирост производительности, хотя больше похоже на враки. В любом случае лично не тестил, а надо бы.
Вы рекомендуете провести ряд проверок, вроде того, чтобы убедиться, не сломана ли у XtraDB постраничная блокировка. Не подскажете, как это всё проверить?
heartdevil: да там особой магии то и нету. При каждом запросе пишем в xcache актуальное время запроса, а так же проверяем, сколько прошло со времени записи в базу (хранится отдельно). Если больше x секунд, то дописывает и в базу. Дописывает через AR модель и метод ->save() (приложение на PhalconPHP).
heartdevil: в том то и проблема, что используется выделение сервер с довольно мощной конфигурацией (чего стоит только i7 4 поколения), но вот именно там оно тормозит.
В общем если найду оптимальное решение, то постараюсь отписать о нём.
heartdevil: и на время записи кроном сайт будет ложиться.
Вероятно для решения этой задачи нужно использовать какое-то внешнее решение и делать ручной JOIN, чтобы вообще избежать запросов к mysql к этой таблице.
heartdevil: А если юзер просто тупо закрыл браузер и ушёл по своим делам? Или у него упал интернет. Или что-то ещё. Был вариант просто-напросто слушать юзера на сокетах и там отлавливать момент отключения, но для этого требуется время на работку, а проблему хотелось бы как-то решить сейчас, хоть и не окончательно.
Анатолий K: а теперь вопрос: откуда мы узнаем время последней активности, если запоминаем только момент входа?
Тут проблема не в том, чтобы затригерить. Нужно помнить, когда юзер последний раз активничал, а за тем, например, выбирать список друзей, сортируя по времени последней активности.
heartdevil: ну получается, что 1 от 1 пользователя. Но часть пользователей держат окно сайта открытым, ожидая, например, уведомлений или сообщений в чат, а это всё pool-запросы, на которых происходит обновление, так что получается немало в сумме.
Анатолий K: дело в том, что точно определить дату выхода не выйдет. Точность не так важна, но хотелось бы знать наверняка, когда последний раз пользователь был на сайте.
Что удивительно, многие движки форумов сохраняют историю вплоть до того, какую страницу ты сейчас просматриваешь и ничего - работают очень даже быстро.
Ну да, я не пометил: актуальные данные пишутся в xcache для отображения самому пользователю, а в базу пишутся раз в N-секунд (сейчас 30). Но ситуация такова, что этого недостаточно - база всё равно забивается именно на обновлении таблицы действий.
Задача стоит так: есть палитра, согласно которой необходимо изменять цвет фона\рамки. Цвет самого текста задаётся программно в зависимости от внутренней логики. При решении в лоб я столкнулся с тем, что не могу переопределить цвет при наведении и при активности элемента, потому и пошёл писать кастыли.
Если вы можете (и что не маловажно хотите) помочь/научить, то мб лучше свяжемся через Skype или Telegram? ErickSkrauch.
Станислав Агафонов: то есть? Сейчас я переделал на события в самом коде примерно так же, как и у вас, только с дополнительной логикой. Пример для hover:
