Сортировка результата CouchDB по отметке времени unix и разбивке на страницы

Question

Я изо всех сил пытаюсь заставить работу нумерации страниц в течение нескольких дней. У меня есть база данных с документами, и у некоторых есть временная метка в качестве ключа для сортировки по убыванию. Но я не могу получить следующий набор документов ...

Если я запусту его, я получу 5 лучших документов. Когда я пытаюсь использовать startkey или startkey_docid, я, похоже, снова получаю те же строки.

Пробуйте документацию кушетки. Я не уверен, что мне нужно, чтобы она работала.

Кушетка имеет такой дизайн:

{
  "_id": "_design/filters",
  "views": {
    "blog": {
      "map": "function (doc) { if (doc.published && doc.type == 'post') emit(doc.header.date); }"
    }
  }
}

. .. header.date генерируется с +new Date()

на nodejs стороне , с github / nano , я использую что-то похожее на:

import nano from 'nano';

let db = nano(SERVICE_URL).use('blog_main');

let lastDocId = ctx.query.lastDocId;
let lastSkip = ctx.query.lastSkip ? +ctx.query.lastSkip + 5 : null;

let query = {
    limit: 1 + 4,       // limit to 5
    descending: true,   // reverse order: newest to top
    include_docs: true,
}
if (lastDocId) { // initally off
    query.startkey = lastDocId;
}
if (lastSkip) { // other method for tests
    query.skip = lastSkip;  //  ----> this results in some previous and some new items
}

let itemRows = await db.view('filters','blog', query);
let items = itemRows.rows;
// each doc is in items[].doc

Я видел сортировку по значению , сортировка работает для меня - но я не могу заставить работать нумерацию страниц.

Answer 1

Используя startkey или skip, возвращенные результаты, которые также включали некоторые из пропущенных результатов, или все предыдущие (странно перепутанные).

Я решил это, расширив ключи результата второй частью. Поскольку ключ основывался на дате без времени, он, похоже, переставлял записи в каждом запросе из-за сходных меток даты и времени. Добавление второй части, которая была сортируемой, а также (использовала созданную временную метку в качестве второй части) исправило ее. Ключ теперь [datetimestamp, createtimestamp] .. оба могут быть отсортированы по убыванию.

Answer 2

Я не уверен относительно утверждения «Я снова получаю те же строки». Это воспроизводимо, если startkey является первым, а не последним ключом предыдущего результата - и это будет первая проблема.

Независимо от того, что startkey является правильным параметром skip и startkey конфликтуют. Первоначально skip должно быть 0, а затем должно быть 1, чтобы пропустить startkey в последовательных запросах.

Этот метод четко описан в документации по пагинации CouchDB ¹ .

Подробности

Предположим, что представление complete (где ключом является unix отметка времени) равно

{
  "total_rows":7,
  "offset":0,
  "rows":[
    {"id":"821985c5140ca583e108653fb6091ac8","key":1580050872331,"value":null},
    {"id":"821985c5140ca583e108653fb6092c3b","key":1580050872332,"value":null},
    {"id":"821985c5140ca583e108653fb6093f47","key":1580050872333,"value":null},
    {"id":"821985c5140ca583e108653fb6094309","key":1580050872334,"value":null},
    {"id":"821985c5140ca583e108653fb6094463","key":1580050872335,"value":null},
    {"id":"821985c5140ca583e108653fb60945f4","key":1580050872336,"value":null},
    {"id":"821985c5140ca583e108653fb60949f3","key":1580050872339,"value":null}
  ]
}

. исходные условия запроса

{
    limit: 5,
    descending: true,
    include_docs: false // for brevity
}

действительно дают ожидаемый результат, 5 строк с самым последним первым

{
  "total_rows":7,
  "offset":0,
  "rows":[
    {"id":"821985c5140ca583e108653fb60949f3","key":1580050872339,"value":null},
    {"id":"821985c5140ca583e108653fb60945f4","key":1580050872336,"value":null},
    {"id":"821985c5140ca583e108653fb6094463","key":1580050872335,"value":null},
    {"id":"821985c5140ca583e108653fb6094309","key":1580050872334,"value":null},
    {"id":"821985c5140ca583e108653fb6093f47","key":1580050872333,"value":null}
  ]
}

Теперь предположим, что второй запрос таков

{
    limit: 5,
    descending: true,
    include_docs: false, // for brevity
    startkey: 1580050872333,
    skip: 5
}

startkey (ключ последней строки предыдущего результата) верен, но параметр skip буквально пропускает следующий (логический) набор строк. В частности, с этими параметрами и приведенным выше примером, запрос будет проходить мимо оставшихся ключей, что приведет к пустому набору строк.

Это то, что нужно:

{
    limit: 5,
    descending: true,
    include_docs: false, // for brevity
    startkey: 1580050872333,
    skip: 1 // just skip the last doc (startkey)
}

1 _{CouchDB Pagination Recipes 3.2.5.5. Пейджинг (альтернативный метод)}