Intégration de données

Exporter un catalogue PostgreSQL cohérent pendant les mises à jour

Hugues Dehen · · 6 min

Un export catalogue peut terminer sans erreur et livrer un ensemble incomplet. Pendant sa lecture, des produits disparaissent, des variantes changent et des prix sont corrigés. Pour un responsable technique, la question consiste à définir précisément quel état doit parvenir au destinataire. Ce guide propose une méthode pour un export complet depuis PostgreSQL, avec un exemple fictif et des preuves de recette. Il distingue trois décisions : ce que l'on lit, comment on parcourt les lignes et quand le résultat devient publiable.

Définir ce que signifie un catalogue cohérent

Commencez par nommer l'unité exportée : produit, variante ou offre par canal. Une ligne par produit ne convient pas nécessairement à un destinataire qui attend une ligne par variante et devise. Écrivez également les filtres d'éligibilité, les relations obligatoires et la signification d'une absence. Un produit absent doit-il être retiré, conservé ou signalé ? Cette décision conditionne le danger d'un export partiel.

Distinguez ensuite cohérence et fraîcheur. Un catalogue représentant un état convenu peut rester exploitable même si des modifications arrivent ensuite. À l'inverse, un assemblage de valeurs récemment lues peut contenir des relations incompatibles. Faites préciser par le métier le retard acceptable et les règles qui rendent un ensemble publiable.

  • Identifier les tables, les jointures et la clé unique de chaque ligne livrée.
  • Fixer les filtres, les devises, les unités et les règles de suppression.
  • Définir une limite de durée et une condition explicite d'abandon.
  • Nommer la personne qui accepte les écarts et autorise la publication.

Reproduire un oubli avec quatre produits

Considérons un scénario entièrement hypothétique. Les produits éligibles portent les identifiants 10, 20, 30 et 40. L'export lit deux lignes par page, dans l'ordre des identifiants. La première page contient 10 et 20. Une autre transaction supprime ensuite 10 et valide cette suppression. La deuxième requête ignore les deux premières lignes de l'ensemble désormais visible : 20 et 30. Elle renvoie 40. Le produit 30 manque au fichier.

Le traitement peut pourtant annoncer trois lignes écrites et aucune erreur SQL. Pour reproduire ce cas en recette, utilisez deux sessions et un point d'arrêt entre les pages. Conservez les identifiants attendus et obtenus. Ce petit jeu montre pourquoi vérifier uniquement le statut du traitement ne suffit pas.

Ajoutez un second scénario : un produit et ses variantes sont modifiés ensemble entre deux lectures. Demandez quel couple de valeurs l'export doit contenir. La réponse permet de définir une attente précise pour les essais de concurrence.

Séparer ordre de parcours et vue de lecture

La documentation PostgreSQL précise que Read Committed peut exposer un état différent à chaque requête. Repeatable Read conserve une vue commune aux lectures successives d'une transaction, établie lors de sa première instruction pertinente. Un ordre unique est également nécessaire pour paginer de manière déterministe. Ces deux propriétés répondent à des problèmes différents.

Pour le cas proposé, retenez comme point de départ une extraction en lecture seule, dans une transaction Repeatable Read, avec une clé de parcours unique et stable. Faites vérifier que toutes les lectures concernées utilisent réellement cette transaction. Un orchestrateur qui ouvre une connexion distincte pour chaque étape ne satisfait pas automatiquement cette condition.

Prévoyez aussi une limite de périmètre : cette démarche vise les données d'une même base. Une lecture PostgreSQL complétée ensuite par une API de prix externe nécessite une règle supplémentaire de rapprochement. Aucun réglage local d'isolation ne définit à lui seul l'état commun de ces deux systèmes.

Choisir une pagination vérifiable

Pour une extraction paginée, proposez un parcours par clé : après la dernière clé livrée, lire les suivantes selon le même ordre. Si le catalogue est défini par produit et variante, le repère doit représenter cette combinaison, avec un départage unique. Documentez le traitement des valeurs nulles et interdisez les changements de règle de tri en cours de lot.

Cette proposition simplifie le repérage des frontières, mais elle ne remplace pas la décision de cohérence. Testez séparément l'ordre et les valeurs obtenues. Une clé de progression décrit un emplacement dans le parcours ; elle ne constitue pas une preuve que toutes les pages appartiennent au même état.

LIMIT/OFFSET reste envisageable sur un ensemble figé. PostgreSQL indique cependant que les lignes sautées doivent encore être calculées. Comparez donc les temps des premières et dernières pages sur un volume représentatif avant de retenir cette solution. La taille des pages doit être mesurée, sans valeur universelle imposée.

Figer les valeurs avant une livraison lente

Si le destinataire traite lentement les données, proposez de séparer extraction et livraison. Le premier traitement produit un lot intermédiaire complet ; le second transmet ce lot. Le dossier doit préciser quels champs sont figés. Conserver seulement les identifiants puis relire les prix pendant l'envoi ne répond pas à l'objectif d'un contenu stable.

Associez au lot un identifiant, le périmètre, la version de transformation, le nombre de lignes et les contrôles effectués. Utilisez des états explicites, par exemple en préparation, validé, publié et abandonné. Le passage à validé doit dépendre des contrôles de contenu, pas seulement de la fin d'écriture.

Ce choix ajoute du stockage et une étape d'exploitation. Une extraction directe peut être plus simple lorsque la fenêtre est courte et maîtrisée. Pour arbitrer, mesurez durée d'extraction, volume intermédiaire, délai de livraison et coût d'un recommencement. Faites examiner les transactions longues et les limites de ressources par l'équipe base de données.

Prévoir l'interruption avant le premier lancement

Décidez ce qui arrive lorsqu'une connexion disparaît à mi-parcours. Dans la méthode proposée, un lot dont l'extraction n'est pas terminée reste non publiable. Si sa vue de lecture n'est plus disponible, recommencez l'extraction sous un nouvel identifiant. Ne présentez pas une simple reprise à la dernière clé comme la continuation certaine du même instantané.

Lorsque le lot complet est déjà figé et validé, la livraison peut faire l'objet d'une reprise distincte. Gardez les preuves d'envoi et de réception associées au même contenu. Convenez aussi du traitement des anciennes tentatives pour empêcher qu'un lot abandonné soit publié ultérieurement par un opérateur ou une relance automatique.

Les erreurs à rechercher pendant la revue

Un comptage réalisé sur la source après l'export n'est pas nécessairement une référence pertinente si cette source continue de changer. Préparez la référence dans le périmètre de lecture retenu. De même, un nombre de lignes identique peut masquer un produit manquant et un autre répété : comparez aussi les clés.

Un instantané conserve un état ; il ne répare pas des données métier déjà contradictoires. Gardez les contrôles de relations et d'éligibilité. Enfin, ne déduisez pas une suppression à destination de l'absence d'une ligne dans un lot incomplet. Exigez d'abord la preuve que l'extraction entière a été validée.

Checklist de recette et décision de publication

Organisez la recette avec des modifications concurrentes déclenchées à des points connus. Pour chaque essai, archivez entrées, chronologie, identifiant du lot, résultats attendus et résultats observés. Les critères ci-dessous sont une proposition à adapter au contrat du destinataire.

  • Comparer l'ensemble des clés exportées à la référence, sans manque ni répétition.
  • Insérer, modifier et supprimer entre deux pages ; vérifier l'état attendu.
  • Tester les variantes et leurs produits parents dans le même scénario.
  • Contrôler une dernière page partielle, un catalogue vide et des valeurs nulles.
  • Couper la connexion avant la fin ; vérifier que le lot reste non publiable.
  • Interrompre la livraison d'un lot validé ; vérifier la conservation du contenu.
  • Mesurer les premières et dernières pages, la durée totale et les ressources.
  • Vérifier que seul un lot complet et accepté peut déclencher des suppressions.

Préparer un diagnostic ciblé

Pour cadrer une intervention, réunissez le schéma utile, les requêtes actuelles, le volume approximatif, les règles du destinataire et un exemple d'écart. Le résultat attendu est une décision documentée sur la lecture, le parcours, la conservation du lot et sa publication. Ces éléments permettent à Sculpture Binaire de discuter d'un périmètre concret, sans présumer qu'une refonte complète du flux est nécessaire.