Exporter ses données en CSV, JSON, SQL, HTML, XLSX et Parquet

Exporter des données depuis un client de base de données semble trivial. En pratique, c'est un problème d'ingénierie qui touche au streaming, à la gestion mémoire, au format de sortie et à l'expérience utilisateur. Dans QoreDB, l'export repose sur un pipeline asynchrone unifié qui alimente six writers distincts : CSV, JSON, SQL INSERT, HTML, XLSX et Parquet.

L'objectif n'était pas d'empiler des formats pour cocher des cases. Chaque format répond à un besoin réel, identifié en contexte de développement quotidien.

Un pipeline de streaming, pas un dump en mémoire

Le point de départ, c'est que l'export ne charge pas l'intégralité du résultat en mémoire avant d'écrire. Le pipeline utilise le streaming natif des drivers (curseurs PostgreSQL, fetch itératif MySQL, etc.) pour consommer les lignes au fil de l'eau. Côté Rust, une tâche tokio::spawn exécute la requête via execute_stream_in_namespace, qui pousse chaque ligne dans un channel mpsc de capacité 100. Le writer consomme ce channel et écrit directement sur disque via un BufWriter asynchrone.

Ce design permet d'exporter des tables de plusieurs millions de lignes sans que la consommation mémoire ne dépasse quelques mégaoctets. Le flush sur disque intervient tous les 1 000 enregistrements par défaut (configurable via batch_size). L'utilisateur peut suivre la progression en temps réel grâce aux événements Tauri émis toutes les 250 ms, avec le nombre de lignes exportées, les octets écrits et le débit en lignes par seconde.

L'export est aussi annulable à tout instant. Un CancellationToken tokio permet d'interrompre proprement le streaming et de libérer les ressources côté driver, y compris l'annulation de la requête en cours sur le serveur de base de données.

Le trait ExportWriter : une interface par format

Tous les formats implémentent le même trait Rust : ExportWriter. Ce trait définit quatre méthodes : write_header pour les colonnes, write_row pour chaque ligne, flush pour forcer l'écriture sur disque, et finish pour finaliser le fichier (écrire un footer HTML, fermer une archive XLSX, etc.).

Cette abstraction permet au pipeline de rester identique quel que soit le format. La fonction create_writer instancie le bon writer selon l'enum ExportFormat, et le pipeline consomme le stream de la même façon. Ajouter un format revient à implémenter le trait et à ajouter une variante dans le match.

Six formats, six cas d'usage

CSV est le format universel. Il fonctionne partout, s'importe dans n'importe quel tableur ou script, et reste léger. Le writer gère l'échappement des guillemets et des retours à la ligne dans les valeurs. L'option include_headers contrôle la présence de la ligne d'en-tête.

JSON produit un tableau d'objets, un par ligne. C'est le format naturel pour alimenter un script, une API, ou un pipeline de traitement. Les types sont préservés : les entiers restent des nombres, les booléens restent des booléens, les valeurs nulles sont explicites.

SQL INSERT génère des statements INSERT INTO prêts à être rejoués sur une base du même moteur. Le writer utilise le SqlDialect du driver source pour produire un SQL syntaxiquement correct (guillemets d'échappement, format des littéraux). Ce format exige un nom de table, validé avant le lancement de l'export.

HTML est le format le plus atypique. QoreDB génère un fichier HTML autonome (self-contained) qui embarque le CSS et le JavaScript nécessaires pour afficher les données avec tri par colonne, filtrage textuel, pagination, et coloration des types. Le fichier s'ouvre dans n'importe quel navigateur, sans serveur ni dépendance externe. C'est le format idéal pour partager un jeu de données à un collègue qui n'a pas QoreDB.

XLSX et Parquet sont des formats professionnels réservés à QoreDB Pro. XLSX permet l'import direct dans Excel avec les types de colonnes préservés. Parquet est un format colonnaire compressé, pensé pour l'analytique et l'ingestion dans des outils comme DuckDB, Spark ou BigQuery. Ces deux writers gèrent leur propre I/O (pas de BufWriter partagé) car leurs formats binaires l'exigent.

En pratique : exporter depuis l'interface

L'export se déclenche depuis le Data Grid ou après exécution d'une requête. L'utilisateur choisit un format, un chemin de destination, et lance l'opération. Une barre de progression apparaît avec le débit en temps réel. Il peut annuler à tout moment sans corrompre le fichier de sortie, car le writer ne finalise qu'à la fin (le footer HTML n'est écrit qu'au finish, l'archive XLSX n'est fermée qu'après la dernière ligne).

L'export passe par la commande Tauri start_export, qui valide le chemin de sortie (il doit être absolu, sans traversée de répertoire parent, dans un dossier existant), vérifie que le driver supporte le streaming, puis lance la tâche asynchrone. Chaque export reçoit un identifiant unique (UUID) qui permet de suivre sa progression ou de l'annuler via cancel_export.

Un paramètre limit permet de borner le nombre de lignes exportées. C'est utile pour extraire un échantillon de données sans attendre l'export complet d'une table volumineuse. Quand la limite est atteinte, le pipeline envoie un signal d'annulation au driver et finalise proprement le fichier.

Pourquoi séparer Core et Pro sur les formats

CSV, JSON, SQL INSERT et HTML couvrent la grande majorité des besoins quotidiens d'un développeur. Ces quatre formats sont disponibles dans la version Core (open source) de QoreDB. XLSX et Parquet, en revanche, ciblent des workflows plus spécialisés : reporting Excel, ingestion analytique, archivage columnar. Ils mobilisent des dépendances Rust supplémentaires et sont compilés conditionnellement via le feature flag "pro". Cette séparation est cohérente avec le modèle open-core de QoreDB : le socle technique reste libre, les formats professionnels font partie de l'offre Pro.

L'export dans QoreDB est un bon exemple de la philosophie du projet : un mécanisme technique propre (pipeline streaming, trait unifié, progression temps réel) au service d'un besoin simple (sortir ses données dans le bon format). Pas de magie, pas de conversion implicite entre moteurs. Le fichier produit contient exactement ce que la requête a retourné, dans le format choisi.