Quand on travaille sur une base de données existante, on a souvent besoin de tester une série de modifications avant de les appliquer. Corriger des données incohérentes, restructurer un jeu de lignes, préparer un import. Le réflexe habituel est d'écrire le SQL à la main, de le tester sur une copie, puis de l'exécuter en production. Ce flux fonctionne, mais il sépare deux moments naturellement liés : explorer les données dans la grille, et produire la migration qui les modifie.
Le Sandbox Mode de QoreDB raccourcit ce trajet. On active le mode, on modifie les cellules dans le data grid comme d'habitude, mais rien n'est envoyé au serveur. Les changements s'accumulent localement, on les revoit, et on les applique d'un bloc en générant le script SQL correspondant. C'est un choix de produit direct : transformer la grille en zone de préparation, sans réinventer un éditeur de migrations.
Modifier sans appliquer
Le principe du sandbox est de découpler l'intention du commit. Quand le mode est actif, chaque édition de cellule, chaque insertion, chaque suppression devient un changement enregistré côté client. Le store frontend (sandboxStore.ts) tient la liste des opérations dans le localStorage, groupées par session de connexion. Trois types de changements sont supportés : insert, update, delete. Chacun garde la primary key d'origine, les valeurs avant et après, et la table concernée.
Le grid affiche ces changements visuellement : une cellule modifiée prend une teinte distincte, une ligne insérée est marquée, une ligne supprimée est barrée ou masquée selon les préférences. Le panneau Changes regroupe le tout par table, avec un compteur par type d'opération. À aucun moment la base n'est touchée. On peut quitter QoreDB et revenir, le sandbox persiste tant qu'on ne le purge pas.
Génération du script de migration
Quand on veut voir ce que ces changements vont produire, le frontend envoie l'ensemble au backend via la commande Tauri generate_migration_sql. Le générateur Rust reçoit la liste des SandboxChangeDto et produit un objet MigrationScript : le SQL textuel, le compte de statements, et d'éventuels warnings. Ce script est spécifique au driver actif. PostgreSQL, MySQL, SQLite et SQL Server génèrent une syntaxe adaptée à leur dialecte, MongoDB sort des opérations natives sur les collections.
Le but n'est pas de masquer la cible. Le SQL produit est lisible, copiable, exécutable ailleurs si besoin. Un développeur peut l'inspecter, le coller dans un fichier de migration de son projet, ou le passer à un DBA pour relecture. Cette transparence est volontaire : le sandbox prépare un changement, il ne le déguise pas.
Indicateur visuel par environnement
Une modification de production n'a pas le même poids qu'une modification de développement. Le composant SandboxIndicator reflète cette différence visuellement. Quand le mode est actif, une pastille apparaît dans la barre supérieure avec un code couleur lié à l'environnement de la session : bleu pour development, orange pour staging, rouge pour production. Le compteur de changements en attente est visible directement dans la pastille.
Ce détail compte parce que le sandbox peut s'activer sur n'importe quelle connexion, y compris une base de prod. Couper la confusion entre "je joue sur une copie locale" et "j'ai 12 changements en attente sur la base de paie" était nécessaire. La couleur ne remplace pas l'attention, mais elle réduit la marge d'erreur quand on jongle entre plusieurs onglets.
Application transactionnelle
L'application des changements passe par la commande apply_sandbox_changes, qui prend la session, la liste des changes et un flag use_transaction. Le backend vérifie d'abord que la session n'est pas en read-only, et que le driver supporte les mutations. Sans ces deux conditions, l'opération est refusée avec un message explicite.
Quand use_transaction vaut true et que le driver supporte les transactions, un BEGIN est émis avant la première opération. Chaque change est appliqué via les méthodes insert_row, update_row ou delete_row du trait DataEngine. Si une opération échoue (conflit de primary key, contrainte violée, ligne disparue), le backend déclenche un rollback automatique et renvoie l'index du change fautif. Le sandbox côté frontend reste intact : on peut corriger le change incriminé et relancer l'apply.
Si le driver ne supporte pas les transactions multi-statement, les changements sont appliqués séquentiellement et chaque échec est consigné dans failed_changes. Le frontend affiche quelles opérations sont passées et lesquelles ont échoué. C'est moins net qu'un rollback global, mais c'est honnête : le moteur cible dicte ses propres règles, le sandbox ne les contredit pas.
Un workflow concret
L'usage type commence par activer le sandbox sur la connexion en cours. On ouvre la table à modifier, on change une dizaine de valeurs, on ajoute deux lignes, on supprime une entrée obsolète. Le panneau Changes montre 13 opérations groupées par table. Avant d'appliquer, on demande la prévisualisation : le SQL généré apparaît dans une vue dédiée. On vérifie les UPDATE, on repère un WHERE fragile, on retourne dans le grid pour ajuster.
Quand le script est satisfaisant, un bouton Apply déclenche la commande backend. Si la transaction est activée, l'ensemble passe ou rien ne passe. La base n'a vu qu'un seul commit, contenant les 13 changements. Le panneau se vide, l'indicateur disparaît, le sandbox redevient inactif. En cas d'erreur, le détail s'affiche et on peut itérer sans repartir de zéro.
Pour les cas où on ne veut pas appliquer mais simplement exporter, copier le SQL est suffisant : on récupère le script, on le commit dans le repo de migrations, on le passe à la CI ou au DBA. Le sandbox a fait son travail de préparation sans imposer un canal d'application unique.
Pourquoi ce design
Le Sandbox Mode est une zone de préparation locale qui rend visible et atomique un travail qui se fait souvent à l'aveugle. Il ne remplace pas un outil de migrations versionnées, ce n'est pas son rôle. Il comble l'espace entre "je modifie une cellule à la main" et "j'écris un script SQL à part" : un endroit où on peut composer une série de changements, les revoir, et les valider en un seul commit. Pour un développeur qui travaille seul ou en petite équipe sur une base partagée, ce raccourci change la nature des micro-corrections de données : elles deviennent traçables, transactionnelles et lisibles avant exécution.
Restez informé des nouveautés
Rejoignez notre newsletter pour recevoir les mises à jour majeures, les nouveaux drivers et nos coulisses techniques.