Seitennummerierung in CouchDB?

Question

Wie würde ich die für die Paginierung erforderlichen Abfragen implementieren?

Grundsätzlich, wenn Seite 1 angefordert wird, erhalten Sie die ersten 5 Einträge. Für Seite 2, holen Sie sich die nächsten 5 und so weiter.

Ich plane, dies über das Couchdb-Python-Modul zu verwenden, aber das sollte für die Implementierung keinen Unterschied machen.

Answer 1

Die CouchDB Guide hat eine gute Diskussion über die Paginierung, darunter viele Beispielcode hier: http://guide.couchdb.org/draft/recipes.html#pagination Hier ist ihr Algorithmus:

• Anfrage rows_per_page + 1 Zeilen aus der Ansicht
• Anzeige rows_per_page Reihen, speichern letzte Zeile als next_startkey
• Als Seiteninformationen, halten startkey und next_startkey
• Über die next_* Werte zum nächsten Link zu erstellen, und die anderen verwenden, um den vorherigen Link

N. B .: Die richtige Art und Weise zu erstellen Seiten zu holen in CouchDB durch die Angabe einer Starttaste, kein Startindex wie Sie vielleicht denken. Aber woher weißt du, welcher Schlüssel zum Start der 2. Seite ist?Die clevere Lösung: "Statt 10 Zeilen für eine Seite anzufordern, fordern Sie 11 Zeilen an, aber nur 10 und verwenden Sie die Werte in der 11. Zeile als Startschlüssel für die nächste Seite." Wenn Sie erwarten, dass mehrere Dokumente identische Schlüssel ausgeben, müssen Sie startdocid zusätzlich zu startkey verwenden, um korrekt zu paginieren. Der Grund ist, dass startkey allein nicht mehr ausreicht, um eine Zeile eindeutig zu identifizieren. Diese Parameter sind nutzlos, wenn Sie keine startkey bereitstellen. Tatsächlich wird CouchDB zuerst den Parameter startkey betrachten und dann den Parameter startdocid verwenden, um den Anfang des Bereichs weiter zu definieren, wenn mehrere potenzielle Startreihen denselben Schlüssel, aber unterschiedliche Dokument-IDs haben. Das gleiche gilt für die .

Answer 2

Dies ist, was ich mit so weit kam haben - die IDs aller Beiträge zu erhalten, dann die eigentlichen Punkte für die ersten x Anzahl der IDs abrufen ..

Es ist nicht sehr effizient, aber um so mehr als alle Posts abrufen, dann den größten Teil wegwerfen. Zu meiner Überraschung schien es ziemlich schnell zu laufen - ich habe die Methode posthelper.page() 100 Mal ausgeführt und es dauerte ungefähr 0,5 Sekunden.

Ich möchte nicht diese in der eigentlichen Frage stellen, so wäre es nicht die Antworten beeinflussen, wie viel - hier ist der Code:

allPostsUuid = """ 
function(doc) { 
if(doc.type == 'post'){ 
    emit(doc._id, null); 
} 
} 
""" 

class PostsHelper: 
    def __init__(self): 
     server = Server(config.dbhost) 
     db = server[config.dbname] 
     return db 


    def _getPostByUuid(self, uuid): 
     return self.db.get(uuid) 

    def page(self, number = 1): 
     number -= 1 # start at zero offset 
     start = number * config.perPage 
     end = start + config.perPage 

     allUuids = [ 
      x.key for x in self.db.query(allPostsUuid) 
     ] 
     ret = [ 
      self._getPostByUuid(x) for x in allUuids[start : end] 
     ] 

     if len(ret) == 0: 
      raise Error404("Invalid page (%s results)" % (len(allUuids))) 
     else: 
      return ret 

Answer 3

Das CouchDB HTTP View API gibt viel Spielraum Paging zu tun effizient . Die einfachste Methode wäre startkey und count. Count ist die maximale Anzahl von Einträgen, die CouchDB für diese Ansichtsanfrage zurückgibt, was Ihrem Design entspricht, und startkey ist der Punkt, an dem CouchDB starten soll. Wenn Sie die Ansicht anfordern, wird Ihnen außerdem angezeigt, wie viele Einträge vorhanden sind. So können Sie berechnen, wie viele Seiten vorhanden sind, wenn Sie dies den Benutzern anzeigen möchten.

Also die erste Anfrage würde keinen Startschlüssel angeben, nur die Anzahl für die Anzahl der Einträge, die Sie anzeigen möchten. Sie können dann den Schlüssel des letzten zurückgegebenen Eintrags notieren und diesen als Startschlüssel für die nächste Seite verwenden. In dieser einfachen Form erhalten Sie eine Überlappung, wobei der letzte Eintrag einer Seite der erste der nächsten ist. Wenn dies nicht erwünscht ist, ist es einfach, den letzten Eintrag der Seite nicht anzuzeigen.

Eine einfachere Methode hierfür ist die Verwendung des Skip-Parameters, um das Startdokument für die Seite zu erstellen. Diese Methode sollte jedoch mit Vorsicht verwendet werden. Der Skip-Parameter bewirkt einfach, dass die interne Engine keine Einträge zurückgibt, über die sie iteriert. Während dies das gewünschte Verhalten ergibt, ist es viel langsamer als das Finden des ersten Dokuments für die Seite nach Schlüssel. Je mehr Dokumente übersprungen werden, desto langsamer wird die Anfrage.