Back to flin
flin

CRUD sans SQL

Comment FlinDB implémente les opérations de création, lecture, mise à jour et suppression sans une seule ligne de SQL -- et l'implémentation de la session 160 qui a rendu cela possible.

Juste A. Gnimavo (Thales) & Claude | March 26, 2026 3 min flin
EN/ FR/ ES
flinflindbcrudqueriesdeveloper-experience

Chaque application jamais construite a besoin de quatre opérations : créer, lire, mettre à jour, supprimer. Ces opérations sont si fondamentales que l'acronyme CRUD est devenu un raccourci industriel pour « gestion de données de base ». Et pourtant en 2026, effectuer ces quatre opérations nécessite encore d'apprendre SQL, de configurer un ORM, ou d'enchaîner des appels de méthodes sur un constructeur de requêtes.

FlinDB fait le CRUD différemment. Il n'y a pas de SQL. Il n'y a pas d'ORM. Il n'y a pas de couche de traduction. Vous sauvegardez une entité, et elle est sauvegardée. Vous cherchez une entité, et elle est trouvée.

Voici l'histoire de la session 160 : 37 tests, 380 lignes de Rust, et une expérience développeur qui fait ressembler les opérations de base de données à des affectations de variables.

Créer : Save et c'est parti

flinuser = User { name: "Thales", email: "[email protected]" }
save user

La méthode save gère à la fois la création et les mises à jour. Si l'entité n'a pas d'ID, c'est une nouvelle entité. Si elle en a déjà un, c'est une mise à jour.

Lire : Find, All, Where, First

flinuser = User.find(1)                          // Find by ID - O(1)
users = User.all                              // All entities
active_users = User.where(active == true)     // Where filter
admin = User.first(role == "admin")           // First match
total = User.count                            // Count

Chaînage de requêtes

flinresults = Product
    .where(category == "electronics")
    .where(price < 1000)
    .order(rating, desc)
    .limit(10)

Mettre à jour : modifier et sauvegarder

flinuser = User.find(1)
user.name = "New Name"
save user

Quand save est appelé sur une entité existante, l'état courant devient une version historique, la nouvelle devient la version courante, le numéro de version s'incrémente et le updated_at est mis à jour.

Supprimer : douce par défaut

flindelete User.find(1)

Toutes les requêtes dans ZeroCore filtrent automatiquement les entités supprimées en douceur. Pour la suppression permanente : destroy user.

L'écart d'expérience développeur

En FLIN :

flin// Create
user = User { name: "Thales", email: "[email protected]" }
save user

// Read
users = User.where(active == true).order(created_at, desc).limit(10)

// Update
user = User.find(1)
user.name = "New Name"
save user

// Delete
delete User.find(1)

La version FLIN se lit comme du pseudocode. Il n'y a pas de client à importer. Pas d'async/await à gérer. Pas d'objets de configuration imbriqués. Les opérations sont des verbes dans le langage, pas des méthodes sur une bibliothèque.

C'est le point. Le CRUD n'est pas la partie intéressante du développement d'applications. C'est la plomberie. FlinDB fait disparaître la plomberie pour que les développeurs puissent se concentrer sur les parties de leur application qui comptent vraiment.


Ceci est la partie 3 de la série « How We Built FlinDB ».

Navigation de la série : - [056] FlinDB: Zero-Configuration Embedded Database - [057] Entities, Not Tables - [058] CRUD Without SQL (vous êtes ici) - [059] Constraints and Validation in FlinDB - [060] Aggregations and Analytics

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