Un catalogue peut afficher un total exact tout en omettant des enregistrements entre les pages. L’audit doit comparer les identifiants uniques reçus par le client, plutôt que le seul nombre de résultats. CRÉER UN JEU REPRODUCTIBLE Dans un environnement de test, créez 75 enregistrements dont plusieurs dizaines partagent la même date et le même prix. Exportez séparément les identifiants attendus. Parcourez toutes les pages de 25 éléments et comparez les deux ensembles. Ce scénario proposé révèle un défaut que des horodatages aléatoires peuvent masquer. Comptez séparément doublons et absences : des totaux égaux ne prouvent pas l’égalité des ensembles. DÉFINIR UN ORDRE COMPLET PostgreSQL ne garantit pas l’ordre souhaité sans ORDER BY. Départagez les valeurs égales par un critère unique, par exemple ORDER BY created_at DESC, id DESC. Appliquez la même règle à la liste, à l’export et au passage suivant. Testez séparément les tris par prix, nom et popularité; chacun doit définir le traitement des égalités. Le second critère appartient au contrat API, pas seulement à la présentation. PRÉVOIR LES CHANGEMENTS EN COURS DE VISITE Un ordre déterministe ne fige pas les données. Des ajouts entre deux requêtes peuvent décaler les positions OFFSET. Pour un flux, envisagez un curseur portant la paire created_at et id, puis poursuivez après la dernière paire reçue. C’est une option de conception, pas une solution universelle. Un export représentant un instantané exige aussi des limites de cohérence et un mécanisme adapté. Un curseur seul ne garantit pas un instantané. VÉRIFIER LE CONTRAT CLIENT Le curseur doit correspondre aux filtres et au tri actifs. Après un changement de catégorie, le parcours recommence. Distinguez une fin de liste d’une panne serveur : résultat vide et requête échouée demandent des états différents. Limitez la taille des pages, validez les entrées et évitez les secrets dans les curseurs. Conservez un journal indiquant tri, filtres, identifiants reçus et changements simultanés. CRITÈRE D’ACCEPTATION Avec des données inchangées, chaque identifiant attendu doit apparaître exactement une fois. Recommencez en ajoutant et supprimant des lignes, puis documentez le comportement prévu. Un avis clair sur les changements vaut mieux que des éléments silencieusement perdus. Catalogue de domaines: https://domainevery.com/fr/domains Sources primaires: 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
