Back to flin
flin

Historique des entités et vues temporelles dans l'admin

Comment la console d'administration de FLIN expose les fonctionnalités de base de données temporelle -- historique des versions d'entités, requêtes voyage dans le temps et la propriété .history qui rend le passé de chaque enregistrement accessible.

Juste A. Gnimavo (Thales) & Claude | March 26, 2026 2 min flin
EN/ FR/ ES
flinadmintemporalentity-historytime-travel

La plupart des bases de données traitent les mises à jour comme des opérations destructrices. La base de données de FLIN est temporelle par conception. Chaque entité suit automatiquement son historique complet de versions. Chaque sauvegarde crée une nouvelle version. Rien n'est jamais véritablement écrasé.

La propriété .history

flintask = Todo.find(4)

{for version in task.history}
    <div class="version-row">
        <span class="version-number">v{version.version}</span>
        <span class="title">{version.title}</span>
        <span class="timestamp">{version.updated_at}</span>
    </div>
{/for}

La propriété .history retourne une liste d'instances d'entités, une par version. Chaque instance historique a tous les mêmes champs que l'enregistrement actuel, plus des métadonnées : version, valid_from et valid_to.

La session 266 a aussi corrigé une régression liée à la gestion des portées dans le moteur de rendu, où les variables de portée n'étaient pas reconnues comme des valeurs côté serveur, causant des symptômes bizarres dans les sélecteurs de langue et les bascules de thème.

Les données temporelles transforment la console d'administration d'un visualiseur de données en un outil forensique. Quand un utilisateur signale que ses données ont changé de manière inattendue, le développeur peut inspecter l'historique pour voir exactement quand et à quelle valeur chaque changement s'est produit.

Le slogan de FLIN est « E flin nu » -- une phrase en Fon signifiant « Il se souvient des choses ». La propriété .history et les vues temporelles de la console en sont l'implémentation littérale.


Ceci est la partie 144 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont amené les capacités de base de données temporelle dans une console d'administration web.

Navigation de la série : - [143] Vues d'administration du stockage et de la base de données - [144] Historique des entités et vues temporelles dans l'admin (vous êtes ici) - [145] Polissage final UI/UX de la console

Share this article:

Responses

Write a response
0/2000
Loading responses...

Related Articles

Thales & Claude thales

Treize agents, quarante-trois minutes : la première session Workflow de Claude Fable 5, et ce qu'un script d'orchestration déterministe change aux builds multi-agents

Un prompt, treize agents, quarante-trois minutes : la première session de production avec Claude Fable 5 et l'outil Workflow de Claude Code a livré un site web de production complet de sept pages plus un endpoint backend de capture de leads, en un seul commit. Le carnet de bord : le script d'orchestration déterministe, le patron d'injection de contrat entre les phases, l'économie par agent du fan-out parallèle, et le suspense de la limite de session que le journal de reprise a transformé en non-événement.

23 min Jun 12, 2026
claude-fable-5claude-codeworkflow-toolmulti-agent +10
Thales & Claude casp

La porte a détecté sa propre dérive : une journée dans CASP avec Claude Fable 5

Nous avons confié au modèle Claude le plus autonome à ce jour les clés de CASP — le CLI open source qui garde les agents de code IA honnêtes face à git — avec l'autorité de rejeter notre propre roadmap. Il a rejeté cinq choses, trouvé deux vrais bugs dans le validateur en le dogfoodant, les a corrigés sous une porte à deux auditeurs, et a laissé casp check entièrement vert sur son propre dépôt pour la première fois. CASP 0.3.0 en est le résultat.

16 min Jun 10, 2026
caspzerosuiteworkflowai-cto +9
Thales & Claude zerosuite

La transplantation du CASP : comment la discipline des six fichiers est passée de Conductor à un ERP transport anti-fraude, ce que la compétence /next ajoute quand l'opérateur tape juste « next », et pourquoi le coût d'une dérive du CASP grimpe quand le projet, c'est l'argent des autres

La discipline du CASP qui a piloté trente-cinq sessions de Conductor est agnostique au produit. Le carnet de bord de sa transplantation sur KASSIA, un ERP transport anti-fraude pour un exploitant de flotte en Côte d'Ivoire : ce qui a migré, ce qui n'a pas migré (le validateur sur mesure — et ce que son absence coûte), ce que la compétence /next ajoute quand l'opérateur tape un seul mot, et là où le CASP s'arrête — le bug de déploiement qu'il ne pouvait pas voir parce qu'il enregistre l'intention, pas la réalité de l'infrastructure.

23 min Jun 8, 2026
kassiaerp-kassia-transport-logistiquezerosuiteCASP +15