L'éditeur SQL de QoreDB : CodeMirror, autocomplétion et choix volontaires

Un client de base de données passe ou casse sur la qualité de son éditeur SQL. C'est l'endroit où le développeur passe le plus de temps, celui où chaque friction se paye en minutes perdues. Quand on a commencé à construire QoreDB, le choix du composant éditeur était donc une décision structurante.

On a retenu CodeMirror 6, la réécriture complète du projet par Marijn Haverbeke. Pas pour suivre une tendance, mais parce que son architecture modulaire permettait exactement ce qu'on cherchait : un éditeur rapide, extensible, et dont on contrôle chaque couche.

Pourquoi CodeMirror 6 et pas Monaco

Monaco, l'éditeur extrait de VS Code, est un choix populaire. Il offre beaucoup de fonctionnalités prêtes à l'emploi. Mais il vient avec un coût : un bundle conséquent, un modèle d'extension opaque, et une intégration lourde dans un contexte non-Electron. QoreDB tourne sur Tauri 2, avec une webview native. On a besoin d'un éditeur qui s'intègre proprement dans un DOM léger, sans charger des mégaoctets de JavaScript au démarrage.

CodeMirror 6 est conçu comme un assemblage de briques indépendantes. On importe uniquement ce qu'on utilise : la coloration syntaxique SQL, l'autocomplétion, les numéros de ligne, la gestion des raccourcis clavier. Le reste n'existe pas dans le bundle. Cette granularité est essentielle dans une application desktop qui doit rester réactive même avec plusieurs onglets ouverts.

L'autre avantage, c'est le système d'état immutable de CodeMirror 6. Chaque modification produit une nouvelle transaction, ce qui s'intègre naturellement avec le modèle React. On peut observer les changements de contenu, contrôler l'éditabilité, et injecter des extensions dynamiquement sans recréer l'instance.

Trois dialectes SQL, un seul composant

QoreDB supporte PostgreSQL, MySQL et SQL Server. Chaque moteur a sa syntaxe, ses mots-clés réservés, ses conventions. Plutôt que de construire un éditeur générique qui nivelle par le bas, on utilise le module @codemirror/lang-sql qui expose des dialectes spécifiques. Quand vous vous connectez à une base PostgreSQL, l'éditeur charge le dialecte PostgreSQL. Les mots-clés, la coloration et les suggestions de complétion correspondent à ce moteur précis.

Ce choix est cohérent avec la philosophie de QoreDB : ne pas abstraire les différences entre moteurs. Si vous écrivez du SQL pour PostgreSQL, votre éditeur parle PostgreSQL. Pas un SQL générique qui masquerait les spécificités du moteur que vous ciblez.

Une autocomplétion basée sur le schéma réel

L'autocomplétion de QoreDB combine trois sources de suggestions, activées simultanément pendant la frappe.

La première source, ce sont les mots-clés SQL du dialecte actif. SELECT, FROM, WHERE, JOIN et tous les mots réservés du moteur courant. CodeMirror fournit cette complétion nativement via son module SQL.

La deuxième source, ce sont les snippets. QoreDB intègre des modèles pour les opérations courantes : SELECT avec WHERE, INSERT INTO, UPDATE, DELETE, JOIN. Chaque snippet utilise le système de placeholders de CodeMirror pour guider la saisie. Vous tapez "sel", vous obtenez un squelette SELECT complet avec des positions de curseur logiques.

La troisième source est la plus intéressante : les métadonnées du schéma. QoreDB interroge le backend Rust pour récupérer les noms de schémas, de tables, de vues et de colonnes de la base connectée. Ces métadonnées alimentent un cache côté frontend avec un TTL de cinq minutes. Quand vous tapez dans l'éditeur, le système analyse le contexte du curseur. Après un FROM ou un JOIN, il propose les tables. Après un point, il propose les colonnes de la table précédente. Si vous écrivez users., vous obtenez la liste des colonnes de la table users, avec leurs types.

Le cache de schéma et l'invalidation

Le cache de métadonnées est un choix délibéré. Interroger le serveur de base de données à chaque frappe serait trop lent et générerait une charge réseau inutile, surtout à travers un tunnel SSH. Le cache est structuré par session : chaque connexion ouverte a ses propres données de schéma.

Le TTL de cinq minutes couvre la majorité des sessions d'écriture courantes. Si le schéma change entre-temps (un ALTER TABLE par exemple), QoreDB invalide le cache de manière ciblée. Quand vous exécutez une opération DDL depuis l'application, le cache des collections ou des colonnes concernées est vidé immédiatement. Cela évite de proposer des colonnes qui n'existent plus, ou de manquer celles qui viennent d'être ajoutées.

Un bouton de rafraîchissement manuel permet aussi de forcer la mise à jour si vous modifiez le schéma en dehors de QoreDB.

Le rôle du backend Rust dans l'introspection

Toute l'introspection de schéma passe par le backend Rust via les commandes Tauri. Le frontend ne parle jamais directement à la base de données. Quand l'éditeur a besoin de la liste des tables d'un schéma, il appelle une commande Rust typée qui exécute la requête appropriée sur le moteur cible.

Chaque driver implémente le trait DataEngine qui expose les méthodes d'introspection : lister les namespaces, lister les collections, décrire une table. Le driver PostgreSQL interroge pg_catalog et information_schema. Le driver MySQL utilise ses propres requêtes système. Le driver MongoDB liste les collections via l'API native. Chaque driver retourne un format unifié que le frontend consomme sans connaître le moteur sous-jacent.

Ce design a un avantage direct : l'autocomplétion fonctionne de la même façon que vous soyez connecté à PostgreSQL, MySQL ou SQL Server. L'expérience est cohérente, mais les données sont toujours celles du moteur réel.

Ce que l'éditeur fait, et ce qu'il ne fait pas

L'éditeur de QoreDB est conçu pour un usage précis : écrire, exécuter et itérer sur des requêtes SQL. Il intègre le formatage automatique via sql-formatter (Cmd+Shift+F), l'exécution par Cmd+Enter (requête complète ou sélection), l'historique persisté par connexion, et les snippets réutilisables via la Query Library.

On a fait le choix de ne pas intégrer de linting en temps réel ni de validation syntaxique avancée. Ces fonctionnalités ajoutent de la complexité et des faux positifs, surtout avec des dialectes SQL variés. Un développeur qui écrit du SQL connaît sa syntaxe. Le retour d'erreur du moteur de base de données est plus fiable et plus précis qu'un parser JavaScript côté client.

De la même façon, l'autocomplétion ne tente pas de deviner l'intention complète d'une requête. Elle propose ce qu'elle sait avec certitude : les objets qui existent dans le schéma, les mots-clés du dialecte, les snippets configurés. Pas de suggestion probabiliste, pas de complétion basée sur l'historique. La précision prime sur l'exhaustivité.

Le multi-onglets et l'isolation par session

QoreDB permet d'ouvrir plusieurs éditeurs en parallèle, chacun lié à sa propre connexion. Chaque onglet possède son instance CodeMirror indépendante, son contenu, son historique, et ses métadonnées de schéma. Vous pouvez écrire une requête PostgreSQL dans un onglet et une requête MySQL dans un autre, chacun avec le bon dialecte et les bonnes suggestions.

L'état de chaque onglet est persisté. Si l'application redémarre, que ce soit volontairement ou après un crash, les éditeurs retrouvent leur contenu. C'est un détail d'implémentation, mais il change l'expérience au quotidien : on ne perd jamais une requête en cours de rédaction.

Le thème, intégré au design system

L'éditeur respecte le thème global de l'application. En mode sombre, il utilise le thème oneDark de CodeMirror, ajusté avec les variables CSS du design system de QoreDB pour que les couleurs de fond, de bordure et de texte soient cohérentes avec le reste de l'interface. En mode clair, les styles par défaut sont remplacés de la même façon. Le changement de thème est instantané, sans recréer l'instance de l'éditeur.

L'éditeur SQL de QoreDB est un assemblage délibéré de composants précis. CodeMirror 6 fournit la base, les dialectes SQL garantissent la fidélité au moteur cible, et l'autocomplétion schema-aware apporte une productivité réelle sans approximation. Chaque décision, du cache de métadonnées à l'absence de linting, reflète un principe simple : donner au développeur des outils fiables et transparents, plutôt qu'une illusion d'intelligence.