Suppression réversible et restauration

Supprimer un enregistrement est non destructif par défaut : la ligne est marquée comme supprimée (deletedAt/deletedBy estampillés) et disparaît des requêtes normales, mais reste récupérable. Cela protège contre les suppressions accidentelles, prend en charge un flux corbeille/annulation et conserve une piste d'audit. La suppression définitive (irréversible) est une opération distincte, régulée par permission, pour les cas qui exigent un effacement irréversible.

Méthode et chemin	Description
`DELETE /api/tables/:tableId/records/:recordId`	Supprimer (réversible) un enregistrement
`DELETE /api/tables/:tableId/records/:recordId?permanent=true`	Supprimer définitivement un enregistrement
`GET /api/tables/:tableId/trash`	Parcourir les enregistrements supprimés de façon réversible
`POST /api/tables/:tableId/records/:recordId/restore`	Restaurer un enregistrement supprimé de façon réversible
`POST /api/tables/:tableId/records/batch/restore`	Restaurer plusieurs enregistrements

Suppression réversible

code

DELETE /api/tables/orders/records/123

Ceci renseigne deletedAt avec l'heure courante et deletedBy avec l'utilisateur agissant, puis exclut la ligne des réponses de liste et de lecture par défaut. L'opération est consignée dans l'historique des modifications de l'enregistrement.

Suppression définitive (irréversible)

code

DELETE /api/tables/orders/records/123?permanent=true

La suppression définitive retire la ligne de façon irréversible et est réservée au rôle admin sur toutes les tables — elle n'est pas configurable via les permissions de la table. Lorsque l'utilisateur n'est pas administrateur, le point de terminaison renvoie 404 (anti-énumération) plutôt que 403.

La suppression définitive est optionnelle et réservée aux administrateurs. Réservez ?permanent=true aux véritables besoins d'effacement — par ex. le droit à l'effacement RGPD sur des données personnelles. Les registres financiers et les tables proches de l'audit ne devraient s'appuyer que sur la suppression réversible. La suppression définitive est une opération irréversible : il n'y a pas de restauration.

Comportement en cascade sur les enregistrements associés

Lorsqu'un enregistrement est supprimé, les enregistrements associés sont traités selon la politique onDelete du champ de relation. Configurez-la sur le champ relationnel.

app.yaml

tables:
  - id: 1
    name: orders
    permissions:
      delete: ['admin', 'member'] # Régit aussi la restauration
    fields:
      - id: 1
        name: customer_id
        type: relationship
        relatedTable: customers
        onDelete: cascade # cascade | set-null | restrict

`onDelete`	Effet lorsque le parent est supprimé
`cascade`	Supprimer également les enregistrements dépendants (enfants)
`set-null`	Effacer la référence de clé étrangère sur les dépendants
`restrict`	Bloquer la suppression tant que des dépendants existent

Vue corbeille

GET /api/tables/:tableId/trash liste les enregistrements supprimés de façon réversible afin qu'une interface puisse présenter une corbeille récupérable. Le même résultat est disponible sur le point de terminaison de liste via includeDeleted=only.

Restauration

code

POST /api/tables/orders/records/123/restore

La restauration efface deletedAt (ramenant la ligne aux requêtes normales), estampille un restored_at, capture l'utilisateur restaurant et consigne l'opération dans l'historique.

app.json

{
  "id": 123,
  "deleted_at": null,
  "restored_at": "2025-01-15T11:00:00Z"
}

Statut	Signification
`200 OK`	Enregistrement restauré
`400 Bad Request`	L'enregistrement n'est pas actuellement supprimé
`401 Unauthorized`	Aucune session active
`404 Not Found`	Enregistrement absent ou non visible

Restauration en lot

Récupérez plusieurs enregistrements en une seule transaction. Les enregistrements qui ne sont pas actuellement supprimés sont ignorés ; un id manquant annule l'ensemble du lot (404). Voir Opérations en lot.

app.json

POST /api/tables/orders/records/batch/restore
{
  "ids": ["123", "124", "125"]
}

Interroger les enregistrements supprimés

Par défaut, les lignes supprimées de façon réversible sont exclues des réponses de liste et de lecture. Remplacez ce comportement avec le paramètre de requête includeDeleted :

Valeur	Comportement
(omis)	Enregistrements actifs uniquement (défaut)
`true`	Enregistrements actifs et supprimés
`only`	Enregistrements supprimés de façon réversible uniquement (équivalent à la vue corbeille)

code

GET /api/tables/orders/records?includeDeleted=true
GET /api/tables/orders/records?includeDeleted=only

Résumé des permissions

Opération	Permission
Suppression réversible	`delete` (selon les permissions de table + RBAC)
Suppression définitive	Rôle `admin` uniquement — non configurable via les permissions de table
Restauration	`delete` — la même autorisation que la suppression réversible, sur les deux points de terminaison de restauration

Pages associées

Vue d'ensemble des enregistrements — auteur deletedBy/deletedAt
CRUD et upsert — le point de terminaison de suppression d'un enregistrement unique
Opérations en lot — suppression et restauration en lot
Champs relationnels — configuration de la cascade onDelete
Historique et commentaires des enregistrements — les suppressions et restaurations sont consignées

Dernière mise à jour 11 août 2026

← PrécédentHistorique et commentaires Suivant →Abonnements en temps réel

Modifier cette page Signaler un problème

Cette documentation a été rédigée avec de l'IA : des erreurs ou du contenu obsolète sont donc possibles. Sovrium est en bêta. Les contributions et corrections sont les bienvenues.