CouchDB нумерация страниц отсортирована по дате, по запросу

Question

Я хочу создать нумерацию страниц на уровне приложения, используя API представления CouchDB.Для разбивки на страницы используются курсоры, поэтому при наличии курсора я буду запрашивать представление для документов n+1, начиная с заданного курсора в качестве клавиши запуска, и выводить результаты n в виде страницы и предоставлять строку результата n+1 в качестве курсораследующая страница.

Это работает хорошо, если ключи просмотра также являются ключами для моих строк просмотра.Теперь на этот раз все мои документы имеют поле даты, и я посылаю их в виде ключей карты, потому что я хочу отсортировать по дате.Однако я больше не могу использовать свои курсоры, как раньше.

Я подумал, что именно поэтому API представления также предоставляет startkey_docid для отправки такого идентификатора документа курсора, однако это, очевидно, неверно.Кажется, что это значение применяется только в том случае, если на ключи приходится несколько одинаковых строк.

Итак, вкратце: я хочу упорядочить по дате, но курсоры на основе идентификаторов документов.Как я могу это сделать?

Заранее спасибо

Simplified view

function map(doc)
{
    emit(doc.date, {_id: doc._id});
}


Simplified view result:

{
"rows":[
    {"id":"123","key":"2010-06-26T01:28:13.555Z", value:{...}},
    {"id":"234","key":"2010-06-22T12:21:23.123Z", value:{...}},
    {"id":"987","key":"2010-06-16T13:48:43.321Z", value:{...}},
    {"id":"103","key":"2010-05-01T17:38:31.123Z", value:{...}},
    {"id":"645","key":"2009-07-21T21:21:13.345Z", value:{...}}
]
}

Application-level query with cursor 234, page size 3 should return:
    234, 987, 103

Так как мне сопоставить это с видом?

Answer 1

Зачем вам курсоры на основе docid?

Map Reduce создает одномерные индексы, поэтому любой обход неключевого ключа будет дорогим.Тем не менее, я думаю, что вы можете делать то, что вы хотите, не требуя обхода двух индексов одновременно.

Посмотрите, например, здесь, как я разбиваю посты с определенным тегом:

Пагинация тега CouchApp на диване

aka

http://jchris.couchone.com/sofa/_design/sofa/_list/index/tags?descending=true&reduce=false&limit=10&startkey=[%22life%22%2C{}]&endkey=[%22life%22]

Ключ в этом представлении выглядит как ["tag", "2008/10/25 04:49: 10 +0000 "], так что вы можете разбивать на страницы по тегам и по тегам по времени.

Отредактировано

Ха!Я только что понял, что ты пытаешься сделать.Это так очень просто.

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

Вы говорите: «Запрос уровня приложения с курсором 234, размер страницы 3 должен возвращаться: 234, 987, 103»

Ваш курсор не должен быть 234. Это должна быть клавиша «2010-06-22T12: 21: 23.123Z ".

Таким образом, по сути, вы используете ключ последней строки результатов в качестве начальной клавиши для следующего запроса.Например, startkey = "" 2010-06-22T12: 21: 23.123Z "" & limit = 3, затем для каждой отображаемой страницы укажите ссылку на запрос, где новый ключ запуска является последним возвращенным ключом.

Bonus: с тем, что я только что описал, нижняя строка страницы 2 будет иметь верхнюю строку страницы 3. Чтобы это исправить, добавьте в свой запрос skip = 1.

Бонусный бонус: ОК, чтоо том, когда у меня более 3 документов, которые отправляются на один и тот же ключ в представлении?Тогда последний ключ всегда будет таким же, как первый ключ, поэтому вы не сможете перейти на нумерацию страниц без расширения параметра limit.Если только вы не используете startkey_docid (и задаете для него идентификатор последней строки).Это единственный раз, когда вы должны использовать startkey_docid.