Cycle de vie et quotas
Un fichier téléversé via les opérations sur les fichiers demeure jusqu'à ce que quelque chose le retire. Deux choses le peuvent : un DELETE explicite, ou la suppression définitive de l'enregistrement qui le référençait. Tout le reste — y compris un enregistrement en suppression douce — laisse les octets en place.
Les fichiers et leurs enregistrements
Les pièces jointes suivent la posture de suppression douce par défaut de Sovrium : la présence du fichier suit donc la présence de l'enregistrement, et non la demande de suppression.
| Ce qui arrive à l'enregistrement | Ce qui arrive au fichier |
|---|---|
| Suppression douce (le défaut) | Conservé. Une restauration récupère la pièce jointe intacte. |
| Restauration | Rien à faire — les octets n'ont jamais bougé. |
Purge (?purge=true) |
Retiré du stockage, puis la ligne est supprimée. |
Suppression dure (?permanent=true) |
Conservé. La ligne part ; les octets sont orphelins. |
| Pièce jointe remplacée lors d'une mise à jour | Le fichier précédent est retiré. |
Pièce jointe vidée à null |
Le fichier précédent est retiré. |
| Clé référencée par un autre enregistrement | Conservé, même pendant une purge. |
Deux lignes méritent attention. La dernière vous sauve : avant de supprimer des octets pendant une purge, Sovrium vérifie qu'aucun autre enregistrement ne pointe vers la même clé — enregistrements en suppression douce inclus — de sorte que deux enregistrements partageant un téléversement ne peuvent pas s'orpheliner mutuellement.
La ligne ?permanent=true est le piège. C'est la suppression dure réservée aux administrateurs, et elle retire la ligne sans toucher au stockage. Utilisez ?purge=true quand le fichier doit partir aussi : elle ne demande que la permission de suppression ordinaire et nettoie les deux côtés.
La purge est irréversible. DELETE /api/tables/{table}/records/{id}?purge=true supprime la ligne et les octets ensemble, sans passage par la corbeille. C'est le DELETE simple qui est réversible ; réservez purge au sens RGPD de l'effacement, pas au sens ménager.
Plafonds de taille
Deux limites contrôlées par l'opérateur bornent les téléversements. Toutes deux sont validées au démarrage : une valeur non entière ou non positive fait refuser le démarrage plutôt que d'ignorer silencieusement votre plafond.
| Variable | Défaut | Portée |
|---|---|---|
STORAGE_MAX_FILE_SIZE |
104857600 (100 Mo) |
Un téléversement. Le maxFileSize d'un bucket prime dessus. |
STORAGE_MAX_TOTAL_SIZE |
illimité | La somme de tous les octets stockés par l'application. |
STORAGE_MAX_FILE_SIZE=52428800 # 50 Mo par fichier
STORAGE_MAX_TOTAL_SIZE=10737418240 # 10 Go au total
Un téléversement trop lourd répond 413 ; un téléversement qui ferait dépasser le quota répond 507. Sans STORAGE_MAX_TOTAL_SIZE défini, aucune vérification de quota n'a lieu : les téléversements ne sont bornés qu'unitairement.
Les téléversements sont mis en tampon, pas diffusés en flux. Le corps de la requête est lu en mémoire avant la vérification de taille : un plafond de 100 Mo signifie donc une allocation de 100 Mo sur une requête acceptée. Réglez STORAGE_MAX_FILE_SIZE — ou le maxFileSize du bucket — au plus petit chiffre viable pour votre application, et traitez-le comme un budget mémoire plutôt que comme une préférence de politique.
Lire l'usage courant
curl https://app.example.com/api/admin/buckets/quota \
-H "Cookie: $ADMIN_SESSION"
{ "totalBytes": 524288000, "fileCount": 1284 }
Le point de terminaison est réservé aux administrateurs et rapporte ce qui est stocké maintenant, pas ce qui est permis — comparez-le à votre propre STORAGE_MAX_TOTAL_SIZE pour connaître la marge restante. Supprimer des fichiers fait baisser totalBytes immédiatement, la valeur étant sommée depuis le stockage plutôt que suivie par un compteur.
Fichiers temporaires d'automatisation
Les automatisations qui écrivent des fichiers de travail les placent sous tmp/automations/. Ceux-ci sont récupérés de façon opportuniste : la prochaine écriture temporaire balaie tout ce qui dépasse le seuil d'âge. Rien n'est planifié, la valeur est donc un âge, pas un intervalle.
| Variable | Défaut | Signification |
|---|---|---|
STORAGE_TEMP_CLEANUP_AFTER |
86400000 (24 h) |
Âge en millisecondes à partir duquel un fichier temporaire est balayable. |
Mettez-la à 0 pour désactiver entièrement le balayage applicatif — le bon choix quand une règle de cycle de vie S3 récupère déjà le préfixe. Toute autre valeur malformée retombe sur 24 heures plutôt que de désactiver le balayage, car une croissance silencieusement illimitée est la pire des défaillances.
Pages associées
- Opérations sur les fichiers — téléverser et supprimer directement.
- Sécurité des téléversements — les validations exécutées avant tout stockage.
- Champs de pièce jointe et stockage — le versant enregistrement de ce cycle de vie.
- CRUD des enregistrements — le point de terminaison de suppression et ses paramètres.
- Variables d'environnement : services — la référence complète
STORAGE_*.
Dernière mise à jour 27 juillet 2026
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.