Le driver MongoDB dans QoreDB : BSON, collections et aggregation pipeline

MongoDB n'est pas une base relationnelle. Pas de schéma imposé, pas de jointures natives entre collections, un modèle de requête qui ressemble plus à un pipeline fonctionnel qu'à du SQL. Un client de base de données généraliste qui prétend l'intégrer doit faire des choix explicites sur ce qu'il expose, sur la façon dont il représente un document dans une grille, et sur les garanties de sécurité qu'il apporte quand l'utilisateur envoie du BSON arbitraire au serveur.

Le driver MongoDB de QoreDB repose sur le driver Rust officiel, avec une couche de validation dédiée au pipeline d'agrégation et une conversion BSON vers JSON qui préserve les types étendus. Voici comment il est construit et pourquoi certaines décisions ont été prises telles quelles.

S'appuyer sur le driver Rust officiel

Le crate mongodb est maintenu par MongoDB Inc. et suit les évolutions du wire protocol. C'est le point de départ le plus sûr pour un client généraliste. QoreDB l'utilise directement, sans wrapper intermédiaire, en s'appuyant sur le Client comme unité de connexion et sur ClientSession pour porter les transactions sur les déploiements qui les supportent.

La chaîne de connexion est construite en interne à partir du ConnectionConfig commun à tous les drivers. L'utilisateur et le mot de passe sont percent-encodés pour ne pas casser le parseur URI quand ils contiennent un @ ou un :. Le timeout de sélection de serveur et le timeout de connexion sont bornés à 10 secondes, pour qu'un host injoignable échoue vite au lieu de bloquer l'interface. Le support des transactions est détecté à la connexion via une commande hello : replica set ou mongos plus sessions logiques activées.

Représenter un document dans une grille

Un résultat SQL tient dans un tableau à colonnes fixes. Un résultat MongoDB, non : deux documents d'une même collection peuvent avoir des clés différentes, des sous-documents imbriqués, des tableaux hétérogènes. Aplatir cette structure pour la mouler dans une grille SQL revient à mentir sur le modèle de données.

QoreDB fait le choix inverse. Chaque document est exposé comme une seule colonne de type json, nommée document. Le Data Grid sait rendre ce type de valeur avec un affichage repliable, du surlignage de clés, et un accès aux champs profonds sans transformation cachée. La conversion BSON vers JSON préserve les types étendus : un ObjectId reste identifiable, un Int64 ne devient pas silencieusement un Double, une Date reste une Date. Les inserts ou updates faits depuis l'inline edit repassent par une conversion inverse qui reconnaît les ObjectId sous forme de chaîne hexadécimale et les rétablit comme tels.

Valider le pipeline d'agrégation avant exécution

L'aggregation pipeline est la partie la plus puissante de MongoDB, et la plus risquée. Trois opérateurs peuvent exécuter du JavaScript côté serveur : $function, $accumulator, $where. Deux stages écrivent dans la base : $out et $merge. Un pipeline suffisamment long peut faire tomber un noeud.

QoreDB embarque un validateur AST dédié dans le module mongo_pipeline. Le pipeline est parsé, chaque stage est classé selon une table blanche d'opérateurs connus, la profondeur maximale est bornée, les opérateurs qui exécutent du code serveur sont rejetés y compris quand ils sont nichés dans une expression. Une limite dure de 50 stages protège contre les pipelines pathologiques. Un pipeline qui se termine par $out ou $merge est classé Mutation, ce qui déclenche les mêmes garde-fous que pour un DELETE en Production : confirmation explicite, blocage par défaut selon l'environnement de la connexion.

Le validateur est fail-closed. Un stage non listé dans la table blanche est rejeté, pas silencieusement autorisé. Ajouter un nouveau stage demande un ajout explicite dans le code, précédé d'une revue de sécurité. Ce choix ralentit l'adoption des nouveautés MongoDB, il évite qu'un opérateur inattendu passe entre les mailles.

Pagination par curseur adaptée au BSON

L'infinite scroll du Data Grid a besoin de pouvoir charger la page suivante sans se décaler quand la collection change. OFFSET n'est pas la bonne primitive dans MongoDB non plus : le coût grimpe avec le rang de la page et les documents insérés entre deux requêtes font glisser les résultats.

Le driver applique la même stratégie keyset que les drivers SQL. À partir du plan de tri, un curseur encode les valeurs des clés du dernier document renvoyé. La page suivante est obtenue par un filtre $or lexicographique construit sur ces valeurs, injecté directement dans le find. Le curseur retombe à None si une clé est absente du document, plutôt que de risquer de sauter des lignes. Les valeurs BSON sont converties vers Value via JSON pour que le curseur puisse porter des ObjectId et des dates et les comparer au retour.

Interroger MongoDB depuis l'éditeur

L'éditeur accepte deux formats. Un raccourci db.collection pour lister rapidement une collection, et une forme JSON complète avec les clés database, collection, operation, query ou pipeline. Cette forme JSON est explicite : le driver ne devine pas l'intention, l'utilisateur déclare l'opération. Le classifieur mongo_safety lit l'opération et route vers la même logique de garde-fous que les autres drivers.

Le sidebar affiche l'arbre bases plus collections comme pour un moteur SQL, avec la même sémantique de navigation. La création de base passe par la création d'une première collection, parce que MongoDB ne matérialise une base qu'à ce moment là. La création se fait via une commande run_command, pas via un DDL synthétique.

Un driver pensé pour l'usage documentaire

Intégrer MongoDB dans un client généraliste ne consiste pas à faire semblant que c'est du SQL. Le driver de QoreDB traite chaque document comme une valeur JSON à part entière, valide le pipeline d'agrégation avant de le transmettre au serveur, adapte la pagination keyset au modèle BSON, et déclare explicitement au serveur les opérations que l'utilisateur a demandées. La sémantique documentaire est respectée, les garde-fous transverses de QoreDB restent en place, et l'utilisateur travaille dans une interface cohérente avec celle qu'il utilise pour PostgreSQL ou SQL Server, sans que le driver ne prétende masquer les différences de modèle.