2017-01-12 2 views
3

Представьте ситуацию, когда клиент покормить объекты с ограничением 10.
Когда следующий 10 требуется он посылает запрос с пропустить 10 и ограничить 10.MongoDB API пагинация

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

Тогда на втором запросе (со смещением == 10) ответ может иметь неправильный порядок объектов.

Сортировка по времени их создания здесь не работает, потому что у меня есть некоторые фиды, которые формируются при сортировке через некоторое числовое поле.

+2

Это не просто проблема MongoDB, она применяется к любой попытке разбиения на страницы на изменяющуюся базу данных. См. Например, http://stackoverflow.com/questions/9394668/pagination-on-fast-changing-database-content –

ответ

1

Вы можете добавить поле времени, например created_at или updated_at. Он должен обновляться, когда документ создается или изменяется, и поле должно быть уникальным.

Затем запросите DB для диапазона времени, используя $ gte и $ lte , а также сортировку на это поле времени.

Это гарантирует, что любые изменения, сделанные вне временного окна, не будут отображаться в разбивке на страницы, если поле времени не имеет дубликатов. Скорее всего, если вы включите microtime, дубликатов не будет.

1

Это действительно зависит от того, что вы хотите получить.

Если вы хотите, чтобы исходные объекты находились в исходном порядке независимо от операций «Удалить» и «Добавить», вам необходимо сделать копию списка (или, по крайней мере, порядка), а затем перейти через страницу. Скопируйте каждый идентификатор в новую коллекцию, которая не изменяется после загрузки страницы и затем разбивается на нее.

В качестве альтернативы, возможно, более вероятно, что вы хотите увидеть следующие 10 после последнего в текущем наборе, включая любые операции удаления или добавления, которые произошли с тех пор. Для этого вы можете использовать отсортированный порядок, в котором вы просматриваете их, и фильтр, $ gt, какой бы ни был последний элемент. НО это не работает, если в поле, в котором вы сортируете, есть дубликаты. Чтобы обойти это, вам нужно будет индексировать в этом поле PLUS другое поле, уникальное для каждой записи, например, поле _id. Теперь вы можете взять последнюю запись в первом наборе и искать записи, которые равны $ eq индексируемому значению, а $ gt - _id ИЛИ - просто $ gt индексированное значение.

Смежные вопросы