Le modèle temporel de FLIN est l'une de ses fonctionnalités les plus distinctives. Chaque entité maintient automatiquement un historique des versions, et les développeurs peuvent naviguer dans cet historique avec l'opérateur @. Le 7 janvier 2026, user @ -1 retournait toujours None, peu importe le nombre de versions existantes. Le modèle temporel était complet dans chaque composant mais échouait dans l'écart entre eux.
Le problème des deux mondes
L'architecture de FLIN a une double personnalité quand il s'agit des entités. Une entité existe simultanément à deux endroits : comme Value::Object sur le tas de la VM, et comme ligne dans la base de données ZeroCore. Après la sauvegarde, la VM mettait à jour l'id de l'entité mais rien d'autre -- le version, created_at, updated_at n'étaient jamais synchronisés depuis la base de données.
La correction : la base de données comme source de vérité
rustmatch self.database.save(&type_name, entity_id, entity.fields.clone()) {
Ok(saved_id) => {
// Fetch the updated entity from the database
if let Ok(Some(saved_entity)) = self.database.find(&type_name, saved_id) {
if let Ok(obj) = self.get_object_mut(obj_id) {
if let ObjectData::Entity(e) = &mut obj.data {
e.id = saved_id;
e.version = saved_entity.version;
e.created_at = saved_entity.created_at;
e.updated_at = saved_entity.updated_at;
e.deleted_at = saved_entity.deleted_at;
}
}
}
}
Err(_e) => { /* error handling */ }
}Le principe de synchronisation
Ce bug a cristallisé un principe de conception qui gouverne désormais toutes les opérations d'entités dans FLIN : après toute mutation de la base de données, synchroniser la représentation de l'entité dans la VM avec la version de la base de données.
La base de données est la source de vérité pour les ID d'entités, les numéros de version, les horodatages et le statut de suppression douce. La VM est la source de vérité pour les valeurs de champs en cours de manipulation et les changements non validés. Le pattern de récupération après sauvegarde ajoute une requête de base de données par opération de sauvegarde, ce qui coûte moins d'une milliseconde en pratique et garantit la cohérence.
Vingt lignes de code. Deux bugs critiques corrigés. Le système entier d'accès temporel -- qui est sans doute la fonctionnalité la plus innovante de FLIN -- est passé de cassé à fonctionnel.
Ceci est la partie 161 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [160] Quand la VM s'est bloquée sur la création d'entités - [161] Le bug de suivi des versions temporelles (vous êtes ici) - [162] La correction de persistance qui a pris 3 sessions