Pourquoi QoreDB n'émule pas les features absentes d'un moteur

Quand on construit un client de base de données qui supporte plusieurs moteurs, une tentation revient sans cesse : combler les écarts. Si PostgreSQL supporte les transactions mais que MongoDB standalone ne le fait pas, pourquoi ne pas simuler un mécanisme transactionnel côté client ? Si Redis n'a pas de schéma, pourquoi ne pas en inférer un automatiquement ? La réponse courte : parce que ce serait mentir au développeur.

QoreDB a fait le choix inverse. Chaque driver déclare explicitement ce qu'il sait faire, et l'interface s'adapte en conséquence. Ce qui n'existe pas dans le moteur n'existe pas dans QoreDB. C'est un principe fondateur du projet.

Le système de capacités déclaratives

Au coeur de l'architecture se trouve la structure DriverCapabilities. Chaque driver remplit un ensemble de flags booléens : transactions, mutations, streaming, maintenance, explain, schema. Ces flags sont lus par le frontend au moment de la connexion, et l'interface masque ou désactive les fonctionnalités qui ne sont pas supportées par le moteur connecté.

Concrètement, si un driver déclare transactions: false, les commandes BEGIN, COMMIT et ROLLBACK ne sont tout simplement pas proposées. Si maintenance: false, le menu VACUUM/ANALYZE/OPTIMIZE n'apparait pas. L'utilisateur ne voit jamais un bouton grisé avec un tooltip "non supporté". Il voit une interface adaptée à son moteur.

L'honnêteté comme contrat avec le développeur

Un client de base de données est un outil de confiance. Le développeur s'en sert pour inspecter des données de production, exécuter des migrations, diagnostiquer des problèmes. Si l'outil simule un comportement que le moteur ne garantit pas, il introduit un risque silencieux. Une transaction émulée côté client qui n'est pas atomique côté serveur, c'est une bombe à retardement.

MongoDB sur un serveur standalone ne supporte pas les transactions multi-documents. C'est une contrainte du moteur, pas un bug du client. QoreDB le déclare via EngineError::NotSupported avec un message clair. Le développeur sait immédiatement qu'il doit passer sur un replica set s'il a besoin de transactions. Il n'est pas induit en erreur par une couche d'abstraction qui masquerait la réalité.

Le même raisonnement s'applique à Redis : pas de schéma relationnel, pas de SQL, pas de jointures. QoreDB propose une navigation par type de clé et des commandes natives. Rien de plus. L'interface reflète ce que Redis est, pas ce qu'on aimerait qu'il soit.

Pourquoi les polyfills SQL sont un piège

Certains outils tentent de traduire les requêtes d'un dialecte SQL vers un autre, ou de simuler des fonctionnalités SQL sur des moteurs NoSQL. L'idée est séduisante sur le papier. En pratique, elle crée trois problèmes.

Premier problème : la sémantique diverge. Un LIMIT PostgreSQL et un TOP SQL Server ne se comportent pas de la même façon en présence de ORDER BY et de valeurs nulles. Traduire l'un vers l'autre exige de connaitre le contexte complet de la requête, ce qui est rarement possible dans un client générique.

Deuxième problème : les performances deviennent imprévisibles. Un polyfill côté client qui émule une jointure entre deux collections MongoDB doit rapatrier les données localement pour les croiser. Sur des tables de quelques milliers de lignes, ça passe. Sur des datasets réels, c'est inutilisable.

Troisième problème : le debugging devient opaque. Quand une requête échoue après traduction, l'erreur remontée par le moteur ne correspond plus à ce que l'utilisateur a écrit. Il faut comprendre la couche de traduction pour diagnostiquer le problème. C'est l'inverse de ce qu'on attend d'un outil de diagnostic.

Une interface qui s'adapte au moteur

Le mécanisme est simple et systématique. Au démarrage d'une session, le frontend demande au backend les capacités du driver connecté via DriverInfo. Cette structure contient l'identifiant du driver, son nom et sa structure DriverCapabilities complète. L'interface conditionne ensuite l'affichage de chaque fonctionnalité.

Pour PostgreSQL, l'utilisateur voit les transactions, le streaming de résultats, les opérations de maintenance, les routines, les triggers. Pour Redis, il voit la navigation par clé, le SCAN, l'inspection par type. Pas de faux boutons, pas de menus vides. L'expérience est taillée pour le moteur réel.

Ce principe s'étend aussi à l'annulation des requêtes. PostgreSQL expose pg_cancel_backend pour un arrêt propre côté serveur. MySQL utilise KILL QUERY. MongoDB ne peut qu'abandonner la tâche côté client, le serveur continue son travail. QoreDB expose le niveau de support réel via CancelSupport : Driver, BestEffort ou None. L'utilisateur est informé de ce qui va réellement se passer quand il clique sur "annuler".

En pratique : ce que voit le développeur

Un développeur connecté à une instance MongoDB standalone ouvre QoreDB. L'arbre de navigation affiche ses bases et collections. L'éditeur propose la syntaxe de requête MongoDB native. Le menu contextuel permet de créer des collections, d'insérer des documents, de lancer des aggregation pipelines. En revanche, pas de bouton "Transaction", pas de menu "Maintenance", pas de génération DDL. Ces éléments n'existent pas parce que MongoDB standalone ne les supporte pas.

Le même développeur se connecte ensuite à PostgreSQL. L'interface se reconfigure. Les transactions apparaissent, les routines et triggers sont accessibles, VACUUM et ANALYZE sont disponibles dans le menu de maintenance. Le changement est automatique et reflète exactement les capacités du moteur.

Si une opération est tentée programmatiquement alors que le driver ne la supporte pas, le backend renvoie une erreur typée avec un message explicite. Pas de stacktrace cryptique, pas de comportement silencieux. Le contrat est clair : QoreDB dit ce qu'il fait, et fait ce qu'il dit.

La transparence comme valeur produit

Ne pas émuler les features absentes, c'est un choix qui simplifie le code, réduit la surface de bugs et renforce la confiance. Le développeur qui utilise QoreDB au quotidien sait qu'il peut se fier à ce que l'interface lui montre. Si un bouton est là, la fonctionnalité est réelle. Si un bouton n'est pas là, c'est que le moteur ne le supporte pas. Cette prévisibilité est ce qui fait la différence entre un outil de travail et un outil qui ajoute de l'incertitude.