Для сайта социальной сети у меня есть активность от людей, за которыми вы следите, и я бы хотел сгруппировать подобные типы событий, сделанных за короткий промежуток времени, для более компактной подачи активности. Представьте, как Facebook отображает список, разделенный запятыми, когда вам «нравятся» сразу несколько вещей: «Джо любит пиво, футбол и чипсы».
Я понимаю, как использовать метод group_by для перечисляемых результатов ActiveRecord, но необходимо выполнить некоторую начальную работу, заполнив свойство, которое я смогу сгруппировать позже. Мои вопросы касаются как хранения данных об активности таким образом, чтобы эти группы можно было пометить, так и последующего их получения снова.
Прямо сейчас у меня есть модель Activity, которая представляет собой ассоциативную связь между пользователем, который совершил действие, и элементом, с которым он связан (в моем примере выше предположим, что «beer», «football» и «chips» являются записи модели Like). Кроме «лайков» есть и другие типы действий (события, сохранение избранного и т. Д.). Что я рассматриваю, так это то, что когда создается эта связь, выполняется проверка, когда была сделана последняя связь этого типа, и, если она была сделана более определенного периода времени назад, увеличивается счетчик «блока деятельности», который является частью модели деятельности. Позже, при рендеринге этого канала активности, я могу сгруппировать по пользователю, затем ввести, а затем этот счетчик блоков активности.
Пример. Допустим, 2 блока обновлений сделаны в течение одного дня. Пользователю нравится 2 вещи в 2:05 и позже еще 3 вещи в 5:45. После того, как третье обновление (начало 2-го блока) происходит в 5:45, модель обнаруживает, что прошло слишком много времени, и увеличивает свой счетчик активности на 1, тем самым вынуждая любые последующие обновления в новый блок, когда они отображаются через group_by вызов:
2:05 Joe likes beer nuts and Hooters.
5:45 Joe likes couches, chips and salsa.
7:00 Joe is attending the Football Viewing Party At Joe's
Мой первый вопрос: какой эффективный способ увеличить счетчик, подобный этому? Это больше не auto_increment, поэтому я думаю, что проще всего смотреть на счетчик последней записи в качестве ориентира. Однако это не может быть из того же запроса, который проверялся при последнем обновлении этого типа, поскольку более позднее обновление другого типа могло уже получить следующее значение счетчика. Они не должны быть глобально уникальными, но это было бы неплохо.
Другой общей стратегией, о которой я подумал, была другая модель, называемая ActivityBlock, которая объединяет группы схожих действий. Во многих случаях обновления будут изолированы сами по себе, поэтому кажется немного неэффективным иметь одну запись для каждого отдельного действия.
Похоже ли что-либо из этого на твердую стратегию?
Мой последний вопрос вращается вокруг нумерации страниц. Теперь, когда мы имеем дело с блоками, труднее всегда отображать точно определенное количество записей, прежде чем начнется разбиение на страницы. Либо отдельное (изолированное) обновление Activity, либо блок из них должны считаться как 1, так что при наименьшем На уровне моего group_by я могу включить счетчик для отслеживания количества отображаемых строк, но это означает, что я больше не могу просто сделать один запрос к БД и просто указать оператор предела. Есть ли способ, которым я все еще мог бы сделать это без повторного выполнения дополнительных SQL-запросов, пока не достигну своего лимита страниц?
Это было бы одним из преимуществ подхода модели ActivityBlock, поскольку я мог бы легко применить к нему вызов limit, и блоки могли бы также содержать счетчик автоматического приращения.