Le Visual Data Diff : comparer Prod et Staging côte à côte

Quand on travaille avec plusieurs environnements de base de données, une question revient souvent : est-ce que les données en staging correspondent à ce qu'on attend en production ? Un enregistrement a-t-il été modifié ? Une ligne a-t-elle disparu après une migration ? Pour répondre à ces questions sans écrire de scripts ad hoc, QoreDB propose un outil intégré de comparaison visuelle des données, le Visual Data Diff.

L'idée est simple : prendre deux jeux de données, les aligner ligne par ligne, et mettre en évidence ce qui a changé. Le principe est le même que celui d'un diff Git, mais appliqué à des résultats de requêtes SQL ou NoSQL.

Deux sources, trois modes

Le diff dans QoreDB repose sur un panneau divisé en deux côtés : une source gauche et une source droite. Chaque côté peut être alimenté de trois façons différentes. Le mode "table" permet de sélectionner directement une table dans une connexion active. Le mode "query" permet d'écrire une requête libre et d'en exécuter le résultat. Le mode "snapshot" permet de charger un état précédemment sauvegardé via le système de snapshots de QoreDB.

Cette flexibilité est importante. Comparer deux tables portant le même nom sur deux serveurs différents est le cas le plus courant, mais ce n'est pas le seul. On peut aussi comparer le résultat d'une requête filtrée avec un snapshot pris la veille, ou deux requêtes différentes sur la même base pour vérifier une hypothèse. Chaque côté du diff est indépendant : connexion, namespace, mode de source, tout peut être configuré séparément.

L'alignement par clé primaire

Pour qu'un diff soit utile, il faut pouvoir associer les lignes entre elles. Si on compare simplement par position (ligne 1 contre ligne 1), le moindre tri différent fausse tout le résultat. QoreDB résout ce problème en utilisant des colonnes clés pour identifier chaque ligne de manière unique.

Par défaut, l'outil tente de détecter automatiquement la clé primaire des tables comparées. Il interroge le schéma des deux côtés via la commande describeTable, récupère les colonnes marquées comme PK, et calcule leur intersection. Si les deux tables partagent la même clé primaire, elle est utilisée directement. Sinon, l'utilisateur peut sélectionner manuellement les colonnes qui servent de clé d'alignement parmi les colonnes communes aux deux résultats.

Ce choix de conception reflète une réalité : toutes les tables n'ont pas de clé primaire explicite, et certaines comparaisons portent sur des résultats de requêtes qui n'ont pas de PK du tout. Plutôt que de refuser le diff dans ces cas, QoreDB permet de comparer sur n'importe quelle combinaison de colonnes, y compris la totalité des colonnes si nécessaire.

Quatre statuts, un code couleur

Chaque ligne du résultat reçoit un statut parmi quatre possibilités. "unchanged" signifie que la ligne existe des deux côtés avec des valeurs identiques. "added" signifie qu'elle n'existe que dans la source droite. "removed" signifie qu'elle n'existe que dans la source gauche. "modified" signifie que la ligne existe des deux côtés mais qu'au moins une cellule a changé de valeur.

L'affichage utilise un code couleur cohérent : vert pour les ajouts, rouge pour les suppressions, orange pour les modifications, et gris pour les lignes inchangées. Pour les cellules modifiées, l'ancienne valeur est affichée en barré au-dessus de la nouvelle. Cette présentation permet de repérer immédiatement ce qui a changé sans avoir à lire chaque cellule.

Une barre de statistiques résume le diff en chiffres : nombre de lignes ajoutées, supprimées, modifiées et inchangées. Chaque compteur est cliquable et sert de filtre rapide. On peut aussi masquer les lignes inchangées pour se concentrer uniquement sur les différences, ce qui est utile quand on compare deux jeux de données volumineux qui ne diffèrent que sur quelques lignes.

Virtualisation et performance

Le diff peut produire des résultats avec des milliers de lignes. Pour que l'interface reste fluide, la grille de résultats utilise la virtualisation via TanStack Virtual. Seules les lignes visibles à l'écran sont rendues dans le DOM, avec un overscan de quelques lignes pour garantir un scroll fluide. Chaque ligne a une hauteur fixe de 36 pixels, ce qui permet au virtualizer de calculer les positions sans mesure dynamique.

Le calcul du diff lui-même est réalisé côté frontend en TypeScript. L'algorithme construit deux maps indexées par clé de ligne, puis itère sur la map gauche pour trouver les correspondances dans la map droite. Les lignes restantes dans la map droite sont marquées comme ajoutées. La comparaison des valeurs gère les cas particuliers : null, objets JSON imbriqués, types mixtes. Le tri final place les suppressions en premier, puis les modifications, les lignes inchangées, et enfin les ajouts.

Cas d'usage concrets

Le scénario le plus fréquent est la vérification post-migration. Après avoir exécuté un script de migration sur un environnement de staging, on compare la table migrée avec son équivalent en production pour s'assurer que seules les modifications attendues ont été appliquées. Les lignes inchangées confirment que le reste des données est intact.

Un autre cas courant est le débogage de données incohérentes. Quand un bug est signalé et qu'on suspecte une divergence entre deux environnements, le diff permet de localiser précisément les lignes et colonnes concernées sans écrire de EXCEPT ou de LEFT JOIN.

Le mode snapshot ajoute une dimension temporelle. En prenant un snapshot avant une opération critique, on peut ensuite comparer l'état actuel avec l'état sauvegardé pour mesurer exactement l'impact des modifications. Cette approche est particulièrement utile pour les opérations de nettoyage de données ou les imports en masse.

Export des résultats

Le résultat d'un diff peut être exporté en CSV ou en JSON. L'export CSV ajoute une colonne _status en première position pour identifier le type de chaque ligne. Pour les lignes modifiées, les cellules concernées affichent l'ancienne et la nouvelle valeur séparées par une flèche. L'export JSON est plus structuré : chaque ligne modifiée contient un objet avec les champs old et new pour les colonnes qui ont changé. Ces exports permettent d'archiver un diff ou de le partager avec un collègue sans que celui-ci ait besoin d'ouvrir QoreDB.

Le Visual Data Diff est un outil de vérification, pas de synchronisation. Il ne génère pas de script de migration et ne modifie aucune donnée. Son rôle est de rendre visible ce qui a changé entre deux états, rapidement et sans ambiguïté. Pour un développeur qui gère plusieurs environnements au quotidien, c'est un raccourci direct entre "je me demande ce qui a changé" et la réponse.