
Ein Katalog kann die richtige Gesamtzahl anzeigen und trotzdem Datensätze zwischen Seiten überspringen. Vergleichen Sie deshalb die beim Client angekommenen eindeutigen IDs, nicht nur die angezeigte Trefferzahl. EIN REPRODUZIERBARER TESTDATENSATZ Erstellen Sie in einer Testumgebung 75 Datensätze und geben Sie mehreren Dutzend dasselbe Datum und denselben Preis. Exportieren Sie die erwarteten IDs mit einer separaten Abfrage. Rufen Sie alle Seiten mit jeweils 25 Einträgen ab und vergleichen Sie beide Mengen. Dieser vorgeschlagene Test macht Fehler sichtbar, die zufällige Zeitstempel verdecken können. Gleiche Anzahlen beweisen nicht, dass die Mengen identisch sind. EINE VOLLSTÄNDIGE SORTIERUNG PostgreSQL garantiert ohne ORDER BY nicht die gewünschte Reihenfolge. Ergänzen Sie bei gleichen Werten ein eindeutiges Kriterium, etwa ORDER BY created_at DESC, id DESC. Liste, Export und nächste Seite müssen dieselbe Regel verwenden. Prüfen Sie Preis-, Namens- und Beliebtheitssortierung getrennt; jede benötigt ein festgelegtes Verhalten bei Gleichstand. Der zweite Schlüssel gehört zum API-Vertrag, nicht nur zur Darstellung. ÄNDERUNGEN WÄHREND DES BESUCHS Eine deterministische Reihenfolge friert die Daten nicht ein. Neue Einträge zwischen Anfragen können OFFSET-Positionen verschieben. Für eine laufende Liste kommt ein Cursor aus created_at und id infrage, der nach dem letzten erhaltenen Paar fortsetzt. Das ist eine Gestaltungsoption, keine universelle Lösung. Ein Export mit einem gemeinsamen Datenstand braucht zusätzlich definierte Konsistenzgrenzen und einen Snapshot-Mechanismus. Ein Cursor allein belegt keine Snapshot-Konsistenz. DEN CLIENT-VERTRAG PRÜFEN Der Cursor muss zu Filtern und Sortierung passen. Nach einem Kategorienwechsel beginnt ein neuer Durchlauf. Listenende und Serverfehler benötigen unterschiedliche verständliche Zustände. Begrenzen Sie die Seitengröße, validieren Sie Eingaben und speichern Sie keine Geheimnisse im Cursor. Notieren Sie im Testprotokoll Sortierung, Filter, erhaltene IDs und parallele Änderungen. ABNAHME Bei unveränderten Daten muss jede erwartete ID genau einmal vorkommen. Wiederholen Sie den Test mit eingefügten und gelöschten Einträgen und dokumentieren Sie das unterstützte Verhalten. Ein ehrlicher Hinweis auf Änderungen ist besser als stillschweigend fehlende Positionen. Domain-Katalog: https://domainevery.com/de/domains Primärquellen: https://www.postgresql.org/docs/current/queries-limit.html https://www.postgresql.org/docs/current/queries-order.html https://www.postgresql.org/docs/current/transaction-iso.html

