Входные данные: есть ньюсфид постов (пусть будет как вконтакте). Допустим, за раз выводится по 5 записей (0-5). При скроллинге к концу подгружается следующая страница (5-10). Так же (с помощью вебсокетов) каждый новый пост автоматически prepend`ится в начало ньюсфида.

Проблема: находясь на первой странице и видя 5 первых постов (0-5), дожидаемся появления нового и его prepend`а в начало (1 + [0-5]), после чего скроллим страничку, подгружается вторая с 5 постами (5-10), но начиная с начала списка, т.е. учитывая появление нового. Таким образом, последний пост первой страницы дублируется первым постом на второй странице.

Выглядит примерно так:
1) имеем
пост №1 (страница №1)
пост №2 (страница №1)
пост №3 (страница №1)
пост №4 (страница №1)
пост №5 (страница №1)
2) подгружается автоматически новый пост и помещается в начало списка:
новый подгруженный и prepend`енный пост
пост №1 (страница №1)
пост №2 (страница №1)
пост №3 (страница №1)
пост №4 (страница №1)
пост №5 (страница №1)
3) скроллим сниз и подгружаем посты второй страницы
новый подгруженный и prepend`енный пост
пост №1 (страница №1)
пост №2 (страница №1)
пост №3 (страница №1)
пост №4 (страница №1)
пост №5 (страница №1)
пост №5 (страница №2)
пост №6 (страница №2)
пост №7 (страница №2)
пост №8 (страница №2)
пост №9 (страница №2)

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

Тему отзеркалил в разделы и по php, и по js, т.к. тут используются обе технологии.

Веди пагинацию по идам сообщений.
тогда дублирования не будет

фидам / видам / IDам?

Если для идентификации поста - начала страницы использовать его timestamp добавления, то никаких проблем нет.
Для подгрузки старых(не отображенных) постов используем время последнего отображенного поста.

что-то навроде

IDам

загружается список с какими-то id, и далее при запросе отправляется номер последнего. where `id`>

Добавлено через 21 секунду
TIMESTAMP всё-таки не обеспечит идеальную точность

У тебя сообщение должно иметь однозначный и уникальный набор параметров который его определяет.
Вот это и использовать в пагинации.

С одним только таймштампом могут быть определенные сложности при агрегации очень активных источников (когда на единицу времени будет приходится большая куча сообщений)

Это сообщение отредактировал(а) Fortop - 13.12.2012, 15:49

Наверное мое упущение, что я не упомянул ограничения.
Проблема в том, что данные получаются не из БД напрямую, а из Сишного демона, так что править его не вариант. Нужно решить проблему малой кровью. Мне в голову пришло следующее:

На js заводим переменную


далее при каждой подгрузке нового поста инкрементим ее, вызовом примерно такой функции:


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

Что это даст?


Какое это имеет значение?
Или записи идут потоком и никак не идентифицируются? 

Aliance, а когда новых постов будет 5 и получится что на второй странице должны погрузиться посты 11-10? =)

Я вот не понимаю, каким образом приложение получает эти пачки постов. Ну из демона. А там есть возможность указать диапазон постов? Или только по номеру страницы? Или как-то еще?

Это сообщение отредактировал(а) Arantir - 13.12.2012, 20:13

То, что мы можем сдвигать offset на это переданное значение.


Значение в том, что задачу нужно решить не изменением демона.


Я же написал псевдокод, где указал, что если подгруженных постов > лимит, то ставим подгруженных постов = 0, а следующую загружаемую страницу увеличиваем на единицу (то есть как бы пропускаем одну страницу, т.к. она уже загружена)


PHP скрипту на вход передается только page, который нужно загрузить. На его основе определяется offset и limit. 
Демону на вход передается только offset и limit.
Я предлагаю передавать php скрипту еще и кол-во уже подгруженных постов, чтобы добавлять их к определенному ранее offset`у.

Я немного перепутал - проблема возникала ровно наоборот, когда новая запись в хранилище появилась, а в ленте у клиента еще нет - тогда возникала такая ситуация. от такого не спастись предложенным мною методом, т.к. loadedPosts еще будет равно нулю. Пришлось пока решить проблему костылём - после загрузки фидов, пробегаюсь по всем js`ом и удаляю дубликаты с одинаковым ID.

Aliance, ну неужели твой демон не возвращает никакого уникального ключа с записью? ну елки палки 

ID записи, безусловно возвращает. Не пойму, что с того?

Ну и ориентируйся по нему для своей пагинации.

вообще говоря, несложно сформировать список отображенных постов. Тем более что, обычно, новые посты имеют больший ID, чем более старые. Если ID странным и непредсказуемым образом перемешаны, можно дополнить их timestamp'ом добавления поста. Для уникальности и определенности.