La suppression est l'opération la plus dangereuse dans toute application. Un mauvais clic, une clause WHERE manquante, un cron job trop zélé, et les données disparaissent. Dans la plupart des systèmes, « disparu » signifie disparu pour toujours. La récupération nécessite des sauvegardes, des restaurations ponctuelles, ou l'intervention divine d'un DBA.
Le modèle temporel de FLIN fait de la suppression un spectre, pas un binaire. Il y a trois niveaux : delete (douce), destroy (dure) et restore (annulation). Chacun a une sémantique claire, des cas d'usage clairs et des implications claires pour la gestion du cycle de vie des données.
Les trois niveaux de suppression
Niveau 1 : suppression douce
Le mot-clé delete marque une entité comme supprimée sans supprimer aucune donnée. L'entité et son historique complet restent dans la base de données, mais elle n'apparaît plus dans les requêtes standard.
flindelete userAprès delete : User.all ne retourne plus cet utilisateur. User.find(id) retourne none. L'historique de l'entité est entièrement préservé. La suppression elle-même devient une version dans l'historique.
Niveau 2 : suppression dure (Destroy)
Le mot-clé destroy supprime définitivement une entité et tout son historique de versions. C'est irrécupérable.
flindestroy userAprès destroy : l'entité est retirée entièrement de la base de données. Tout l'historique de versions est purgé. .history retourne une liste vide. Il n'y a pas de chemin de récupération.
La suppression dure existe pour un cas d'usage principal : la conformité réglementaire. Le « droit à l'oubli » du RGPD exige la capacité d'effacer définitivement les données d'une personne -- pas juste les cacher, mais les supprimer pour qu'aucune trace ne reste.
Niveau 3 : Restauration
La fonction restore() inverse une suppression douce, ramenant une entité supprimée dans les requêtes actives.
flindelete user // Soft deleted
restore(user) // Undeleted -- entity is active againLa chronologie de versions pour un cycle complet suppression-restauration ressemble à ceci :
v1: Created v2: Updated v3: Deleted v4: Restored
(active) (active) (deleted) (active)Chaque transition est une version. Chaque version est immuable. Le cycle de vie complet est traçable.
Corrections de bugs
Bug 1 : plage de validation des opcodes. L'opcode Destroy était assigné à la valeur 0x9A, mais la plage de validation ne couvrait que 0x90..=0x99. Un caractère. Un octet. La différence entre une fonctionnalité qui marche et une qui plante.
Bug 2 : entités fantômes après Destroy. Après destroy, l'objet entité existait encore dans le tas de la VM. La correction a ajouté une vérification d'existence avant d'ajouter la version courante.
Bug 3 : Restore comme mot-clé vs. fonction. restore était défini comme un mot-clé dans le lexeur, mais contrairement à delete et destroy, restore prend un argument : restore(user). La correction a été de retirer restore de la liste des mots-clés et de l'enregistrer comme fonction intégrée.
Pourquoi trois niveaux sont importants
La suppression douce (delete) est pour la suppression côté utilisateur. Quand un utilisateur supprime un document, les données doivent être récupérables.
La suppression dure (destroy) est pour la conformité réglementaire. L'article 17 du RGPD accorde aux individus le « droit à l'effacement ». Un delete ne satisfait pas cette exigence parce que les données existent encore dans la base de données. destroy si.
flin// GDPR erasure request
fn handle_erasure_request(user_id) {
user = User.find(user_id)
if user {
destroy user // Permanent. No trace remains.
}
}La restauration est le filet de sécurité. Elle permet la fonctionnalité d'annulation, la récupération de données et la résilience opérationnelle.
RGPD et le droit à l'oubli
Le modèle de suppression à trois niveaux de FLIN correspond directement aux exigences du RGPD :
- La suppression douce satisfait la « désactivation de compte » -- les données de l'utilisateur ne sont plus visibles mais peuvent être réactivées.
- Destroy satisfait le « droit à l'effacement » (article 17) -- toutes les données personnelles et leur historique sont définitivement supprimées.
- Le modèle temporel lui-même satisfait le « droit d'accès » (article 15) -- l'historique complet des changements de données est disponible pour l'export.
Intégrer ces mécanismes de conformité dans le langage signifie que chaque application FLIN obtient une gestion du cycle de vie des données compatible RGPD sans aucun code supplémentaire.
Ceci est la partie 4 de la série sur le modèle temporel de « How We Built FLIN », documentant le modèle de suppression à trois niveaux et ses implications RGPD.
Navigation de la série : - [046] Every Entity Remembers Everything: The Temporal Model - [047] Version History and Time Travel Queries - [048] Temporal Integration: From Bugs to 100% Test Coverage - [049] Destroy and Restore: Soft Deletes Done Right (vous êtes ici) - [050] Temporal Filtering and Ordering