Nous avons publié un nouveau paquet appelé spatie/laravel-deleted-models. Lors de la suppression d’un modèle, ce package copiera ses attributs dans une table appelée deleted_models
.
Vous pouvez afficher ce package comme une “Corbeille pour les modèles”.
Dans cet article, j’aimerais tout vous raconter.
Utilisation du forfait
L’installation du package n’est qu’une simple installation de compositeur.
composer require spatie/laravel-deleted-models
Après cela, vous devez publier et exécuter des migrations pour créer deleted_models
tableau.
php artisan vendor:publish --tag="deleted-models-migrations"
php artisan migrate
Une fois le package installé, vous devez utiliser le KeepsDeletedModels
trait sur chaque modèle Eloquent où vous souhaitez conserver les attributs lorsque le modèle est supprimé.
use Illuminate\Database\Eloquent\Model;
use Spatie\DeletedModels\Models\Concerns\KeepsDeletedModels;
class BlogPost extends Model
{
use KeepsDeletedModels;
}
Lorsque vous appelez delete sur un modèle, ses attributs seront copiés dans deleted_models
.
$blogPost = BlogPost::find($id);
// values will be copied to the `deleted_models` table
$blogPost->delete();
Pour restaurer un modèle supprimé, vous pouvez appeler restore
et passer dans le id
.
// $blogPost will be restored and returned
$blogPost = Blogpost::restore($id);
Vous pouvez également restaurer le modèle en mémoire sans l’enregistrer encore dans la base de données, ce qui vous permet d’apporter des modifications avant de l’enregistrer.
// the `$blogPost` isn't saved yet
$blogPost = BlogPost::makeRestored($id);
// make some modifications to the blog post
// ...
$blogPost->save();
Le package a plus de fonctionnalités et l’ensemble du processus de suppression / restauration peut être personnalisé. Rendez-vous sur la documentation sur GitHub pour en savoir plus.
Les compromis par rapport aux suppressions réversibles
Dans l’écosystème Laravel, il existe une autre méthode populaire pour conserver les enregistrements supprimés : la suppression logicielle. Lorsque vous utilisez des suppressions réversibles, vous ajoutez un deleted_at
colonne à chaque tableau. Lorsque cette colonne a une valeur, elle doit être considérée comme supprimée et vous devez veiller à ne pas sélectionner ces enregistrements lors de l’exécution de requêtes dans le cadre du fonctionnement normal de votre application.
Le grand avantage des suppressions douces est que c’est très pratique. Aucune donnée ne doit être copiée lors de la suppression d’un modèle. De plus, lorsque vous effectuez des migrations sur une table qui utilise des suppressions réversibles, ces enregistrements “supprimés” seront mis à jour.
Mais il y a aussi des inconvénients importants. Vous devez toujours garder à l’esprit les suppressions réversibles chaque fois que vous effectuez une requête via Eloquent ou lorsque vous effectuez une requête directement sur votre base de données. Il est très facile d’oublier une clause where pour omettre ces enregistrements supprimés en douceur.
Lorsque vous utilisez des suppressions réversibles, vous perdez également les avantages de votre base de données qui applique l’intégrité référentielle. Autrement dit, si vous supprimez en douceur un enregistrement vers lequel d’autres enregistrements pointent via une clé étrangère, vous devez mettre à jour manuellement ces enregistrements pour qu’ils soient également supprimés en douceur. Avec les suppressions réversibles, votre base de données ne peut pas appliquer l’intégrité référentielle.
La purge définitive des données de toutes les tables contenant des enregistrements supprimés de manière réversible implique la surveillance et l’exécution de requêtes de suppression pour toutes ces tables. Une simple requête ne suffit généralement pas pour supprimer toutes les anciennes données supprimées de manière réversible.
Pour annuler la suppression d’un enregistrement supprimé de manière réversible, cela peut être aussi simple que de définir le deleted_at
à nul. Dans de nombreux cas, il en faut plus. Vous devez également restaurer tous les enregistrements associés, et la suppression d’origine peut avoir déclenché des effets secondaires en dehors de votre base de données que vous devrez annuler. Dans de nombreux cas, une restauration comprendra plus que la simple mise à jour du deleted_at
.
À l’aide d’un deleted_models
table résout certains, mais pas tous, des problèmes décrits ci-dessus, mais pas tous. C’est simplement un autre ensemble de compromis. Utilisant un deleted_models
pour les modèles supprimés :
- ne vous oblige pas à adapter vos requêtes. Vous pouvez simplement sélectionner des éléments de la table d’origine sans avoir besoin d’un supplément
where deleted_at = null
- permettre à votre base de données de toujours protéger l’intégrité référentielle de votre base de données. La suppression d’un enregistrement supprimera également tous les enregistrements associés.
- faciliter la suppression permanente de toutes les anciennes données. Il s’agit simplement d’effectuer une requête de suppression l’une après l’autre
deleted_models
tableau avecwhere data_created < <your-treshold-date>
. - rendre plus difficile la restauration des données supprimées car vous devez recopier des éléments (au lieu de simplement configurer
deleted_at
pournull
lors de l’utilisation de suppressions réversibles)
En conclusion
Notre package spatie/laravel-deleted-models facilite la copie de tous les enregistrements supprimés dans une table. C’est une stratégie alternative pour les suppressions réversibles.
Les deux stratégies ont leurs propres avantages et inconvénients. Décidez laquelle des deux solutions offre les meilleurs compromis pour votre projet.
Ce package et cet article de blog ont été inspirés par ces deux articles de blog :
Ce forfait n’est pas le premier forfait Spatie. Veuillez consulter cette longue liste de packages Laravel et PHP que nous avons créés auparavant. Je suis sûr qu’il y a quelque chose là-bas pour votre prochain projet. Si vous souhaitez soutenir nos efforts open source, envisagez de choisir l’un de nos produits payants ou de vous abonner à Mailcoach et/ou Flare.