Bug: `/events` ignoriert limit parameter, wenn `direction` nicht vorhanden ist

liebsoer

Moin

mir ist aufgefallen, dass der Endpunkt /events den Request Parameter limit ignoriert, wenn der Request Parameter direction nicht angegeben ist.

Wenn ich z.B. ?limit=1 setze bekomme ich mehr als ein Ergebnis zurück. Wenn ich ?direction=forward&limit=1 setze, dann erhalte ich wie erwartet nur ein Ergebnis zurück.

Wir verwenden die Version 3.108.2 (Build 32253).

Viele Grüße
Sören

thommyb

@liebsoer Der /events Endpunkt vereint zwei Paginierungs-modelle, nämlich über page und limit oder (alternativ) über ein Zeitfenster. Und der "Umschalter" zwischen diesen beiden ist die Richtung (direction). Wenn du also nur ein Limit angibst, dann wird dieses ignoriert und ein Zeitfenster von heute bis heute + 2 Monate genommen.

Da ich selber (als Anwender) auch schon darüber gestolpert bin (finde gerade meine beinahe identische Frage in diesem Forum nicht), ergänze ich die Doku gleich mal.

liebsoer

@thommyb Super, vielen Dank für das Doku aktualisieren. Gibt es für limit einen default Wert oder wird ohne diesen parameter alles, was in dem Zeitraum liegt zurück gegeben? Also auch, wenn in dem Zeitraum 1000 Events existieren?

Sinnvoll fände ich default Werte für folgende Parameter:

page: 1
limit: z.B. 10
canceled: false

Was mir bei dem Endpunkt auch fehlt ist eine Information darüber, wieviele Ergebnisse überhaupt in dem Suchzeitraum existieren.

Wenn ich direction=forward&limit=1 erhalte ich in dem Meta-Feld nur die Information, das es 1 Ergebnis gibt. Mir fehlt sowas wie results oder pages das mir sagt, wie weit ich den noch paginieren kann.
Alternativ fände ich auch ein next und previous Meta-Feld gut, das die URI von der nächsten bzw. vorherigen Seite enthält, damit ich in meinem Skript über die Felder schön navigieren kann.

liebsoer

Bei /api/groups habe ich gerade folgendes Meta-Feld gefunden:

{
  "meta": {
    "count": 10,
    "all": 78,
    "pagination": {
      "total": 64,
      "limit": 10,
      "current": 1,
      "lastPage": 7
    }
  }
}

Das wäre genau, was ich mit für /events auch wünsche.

thommyb

@liebsoer Natürlich haben page und limit geeignete Default-Werte. (Beim limit diskutieren wir gerade noch, ob wir den Default auf 10 herabsetzen, um den Wert konsistent mit den meisten anderen unserer paginierenden APIs zu machen.)

Ein generelles Problem ist die von dir angesprochene Gesamtzahl der Ergebnisse. Wo wir sowieso alle Objekte laden (müssen), ist es leicht, auch die Gesamtzahl zurückzugeben. Wenn wir die Paginierung jedoch über SQL offset und limit abfackeln, steht uns diese Gesamtzahl nicht zur Verfügung, sondern müsste zusätzlich ermittelt werden, was in der Regel zulasten der Performance geht.