Scheduled job to clean out Laravel's soft deleted records at configured interval.
The soft deletes are great in Laravel to make sure that some deleted data can be recovered. This package allows you to configure an array of models with how many days that you want the soft deleted data to stay in the database.
As side from Laravel >= 5.1.10 (5.1.10 is the first version that had the warn method, so that is the minimum for logging), there is 1 package that is required.
Install Garbage Man:
$ composer require spinen/laravel-garbage-man
The package uses the auto registration feature of Laravel 5.
As of Laravel 5.8 (and deprecated in 5.4), the
fire() method on the dispatcher contract was removed in favor of
dispatch(). Therefore, we have updated our code to use
dispatch(). You will need to change
dispatch() in your
The command is registered with laravel as
garbageman:purge. You can run it one of 2 ways...
- from the command line
php artisan garbageman:purge;
- via a scheduled task.
To automatically run the script as a scheduled job, then add the following to the schedule method of
You can use whatever schedule that you need to keep the records purged out. Just review the list at http://laravel.com/docs/master/scheduling#schedule-frequency-options.
You can also use any of the advanced configuration options of the task scheduler like "Task Output" or "Task Hooks" as listed on the Laravel documentation.
Publish the package config file to
$ php artisan vendor:publish
This file is fully documented. You will need to make the changes to that file to suit your needs. There are 3 main configuration items...
- Dispatch purge events - Dispatch events on purge of each record.
- Logging level - Level to log.
- Schedule - Models & number of days to allow the soft deleted record to stay before purging.
You may hook into the purge of each record by throwing events before & after deleting of each record. There are 2 events thrown:
The model is passed with each of the events. The "purging" event is thrown just before the actual delete & "purged" is thrown just after the actual deletion.
Please note: This is an expensive operation as it requires a SQL command for each record to delete so that the record can be thrown with the events. Therefore, unless you need to catch the events to perform some other action, leave this false to allow all records per model to get deleted with a single SQL call.
The level that log messages are generated, which will display information on the console output and in the logs.
|0||Emergency: system is unusable|
|1||Alert: action must be taken immediately|
|2||Critical: critical conditions|
|3||Error: error conditions|
|4||Warning: warning conditions|
|5||Notice: normal but significant condition|
|6 (default)||Info: informational messages|
|7||Debug: debug - level messages|
There is a key for the console & one for the log. Here is an example...
'logging_level' => [ 'console' => 3, 'log' => 6, ],
Alternatively, you can set the levels with environmental variables
The age is in days for each model. Here is an example...
'schedule' => [ App\ModelOne::class => 14, App\ModelTwo::class => 30, ],
This would purge any ModelOnes that were deleted over 14 days ago and any ModelTwos that were deleted over 30 days ago.