Le modèle de drivers dans QoreDB : choix, contraintes, limites

Un noyau commun, des moteurs natifs

Le modèle de drivers de QoreDB repose sur une architecture que l’on peut résumer ainsi :

Kernel unique, drivers natifs intégrés.

QoreDB n’utilise :

• ni ODBC / JDBC (abstraction totale),
• ni drivers JavaScript exécutés dans une couche Electron,
• ni traduction intermédiaire des requêtes.

Chaque moteur est implémenté nativement en Rust, compilé dans le binaire, et exposé via une interface commune minimale.

Ce choix impose des contraintes réelles.
Il apporte aussi des garanties fortes en termes de contrôle, de performance et de lisibilité architecturale.

1. Isolation par session

Le pattern « 1 session = 1 pool »

Dans QoreDB, chaque onglet ou session utilisateur instancie son propre contexte de connexion.

Concrètement :

• PostgreSQL utilise un PgPool dédié par session.
• MongoDB utilise un Client dédié par session.

Avantage principal : isolation totale

Une session bloquée, une requête lourde ou un crash n’impacte jamais :

• les autres onglets,
• les autres connexions,
• l’état global de l’application.

Chaque session est un espace isolé.

Contrainte directe : consommation de connexions

Cette approche a un coût mesurable.

Exemple :

• 1 pool = 5 connexions max (par défaut)
• 10 onglets ouverts sur la même base
• jusqu’à 50 connexions simultanées possibles

QoreDB privilégie l’isolation et la robustesse au détriment d’une optimisation agressive du nombre de connexions.

C’est un choix explicite.

2. Le « faux SQL » pour NoSQL

Une concession contrôlée

L’interface unifiée DataEngine impose une méthode simple :

execute(query: &str)

Pour PostgreSQL, cela ne pose aucun problème :
le langage est SQL.

Pour MongoDB, la situation est différente.

La réalité côté MongoDB

QoreDB n’exécute pas de JavaScript dans l’éditeur Mongo :

• pas de boucles,
• pas de variables,
• pas de logique procédurale.

Le driver attend du JSON strict, représentant une commande Mongo native.

Fonctionnement :

• si l’entrée est un JSON valide (find, aggregate, etc.), elle est exécutée directement ;
• si l’entrée ressemble à une syntaxe de type db.users.find(...), un fallback syntaxique tente de la convertir en JSON.

Limite assumée

L’éditeur Mongo de QoreDB est un éditeur de requêtes, pas un environnement de scripting.

C’est une contrainte volontaire :

• plus simple à sécuriser,
• plus prévisible,
• alignée avec le reste de l’architecture.

3. Inférence de schéma pour le NoSQL

Une approximation nécessaire

MongoDB est schéma-less par définition.
L’interface, elle, a besoin d’une structure pour :

• l’arbre de navigation,
• l’autocomplétion,
• la grille de résultats.

La solution retenue est une inférence par échantillonnage.

Fonctionnement

Pour décrire une collection :

• QoreDB lit les 100 premiers documents,
• en déduit une structure probable,
• l’expose à l’interface.

Limite structurelle

Si un champ :

• apparaît rarement,
• ou uniquement dans des documents tardifs,

il peut ne pas être visible dans :

• l’autocomplétion,
• la structure affichée.

QoreDB n’invente pas un schéma global.
Il montre une vision partielle mais honnête de la réalité.

4. Transactions : asymétrie assumée

Les transactions sont gérées selon les capacités réelles du moteur.

PostgreSQL

Support complet.

• Une transaction réserve une connexion dédiée du pool.
• Toutes les requêtes passent par ce canal unique.
• La transaction est strictement respectée jusqu’au COMMIT ou ROLLBACK.

MongoDB

Le driver détecte au démarrage si les transactions sont supportées.

Limite critique :

• MongoDB en mode Standalone (cas classique en local) ne supporte pas les transactions.
• Elles ne sont disponibles que sur des Replica Sets.

QoreDB :

• ne les émule pas,
• ne les simule pas,
• ne ment pas à l’utilisateur.

Si le moteur ne supporte pas une fonctionnalité, l’outil ne la fabrique pas artificiellement.

5. Streaming et performance

Ne jamais charger tout en mémoire

Un problème classique des outils desktop basés sur Electron :

• chargement massif de résultats en mémoire,
• sérialisation complète en JSON,
• freeze de l’interface.

QoreDB adopte une approche différente.

Fonctionnement

Les drivers implémentent un mode de streaming :

• les résultats sont lus ligne par ligne (ou par batch),
• transitent via des streams asynchrones Rust,
• sont envoyés progressivement au frontend.

À aucun moment :

• l’intégralité du dataset n’est chargée en RAM,
• un gros SELECT ne bloque toute l’application.

C’est un choix structurel qui permet à QoreDB de rester utilisable sur de très gros volumes.

Conclusion

Le modèle de drivers de QoreDB n’est pas neutre.

Il :

• privilégie l’isolation à l’optimisation extrême,
• préfère des limites explicites à des abstractions trompeuses,
• expose les capacités réelles des moteurs au lieu de les uniformiser artificiellement.

QoreDB n’essaie pas d’être plus intelligent que les bases qu’il manipule.

Il s’efforce d’être :

• un intermédiaire fiable,
• un exécuteur honnête,
• un outil qui ne cache pas la complexité, mais la rend manipulable.