Problème
Comprendre comment un moteur de base de données documentaire fonctionne sous le capot, en partant de zéro : persistence binaire, schémas, async I/O.
Contexte
Projet d'apprentissage personnel, inspiré de MongoDB. Stalled : la couche réseau et le query language ne sont pas implémentés.
Stack technique
- Rust (edition 2024)
- Tokio (full features)
- Serde + bincode (serialization binaire)
- serde_json
- log + env_logger
Décisions techniques
- Module-par-concept (`database/`, `collections/`, `document/`, `schema/`, `storage/`) plutôt qu'une architecture en couches — plus facile à explorer en apprentissage.
- Schema-first : la validation se fait avant l'écriture, pas à la lecture. Force à penser la cohérence des types en amont.
- bincode plutôt que JSON pour le stockage : binaire compact, mais lecture humaine impossible (compromis assumé).
- Tokio dès le départ pour les I/O fichier, même si ça ajoute de la complexité — pour apprendre l'async Rust en condition réelle.
- Trait `ToSchema` sur `HashMap<String, FieldType>` pour définir un schéma de collection sans macros.
Difficultés
- Dualité `Document` (en mémoire) vs `StoredDocument` (sur disque) qui divergent au reload — dette technique pas encore résolue.
- `storage::bin_to_json` cassé (variables `src` et `config` non définies) — empêche la lecture des `.bin` existants.
- Pas de chemin de désérialisation : `Collection::new` ré-initialise toujours un `Vec` vide, donc les données sont write-only en pratique.
Résultats
- Implémenté : création de databases/collections, schémas typés (5 types), validation à l'insertion, écriture binaire async.
- Pas implémenté : read, update, delete, query, networking. Stalled en attendant que je revienne dessus.