Problem
Every API request inserts a row with three JSON blobs (request_data, request_headers, response_data), so the api_logs table grows unbounded. The package currently offers no retention, pruning, or purging mechanism, leaving cleanup entirely to the consuming application.
Proposal
Use Laravel's built-in pruning machinery instead of a custom command:
- Add the
Illuminate\Database\Eloquent\MassPrunable trait to ApiLog.
- Implement
prunable() returning a builder scoped to created_at < now()->subDays(config('api-logs.prune_after_days')).
- Add a
prune_after_days key to config/api-logs.php, defaulting to null (pruning disabled) so upgrading never silently deletes data.
- When the config value is
null, prunable() should match no rows.
Consumers opt in by setting the config value and scheduling the framework command:
Schedule::command('model:prune', [
'--model' => [\CodeTech\ApiLogs\Models\ApiLog::class],
])->daily();
MassPrunable is preferred over Prunable: deletes run in chunked mass DELETE queries without hydrating models, which suits log data with no relationships to cascade or events to fire.
Documentation
README should document the config key and the scheduler snippet, noting that a bare model:prune only auto-discovers models in app/Models, so the explicit --model option is required for package models.
Problem
Every API request inserts a row with three JSON blobs (
request_data,request_headers,response_data), so theapi_logstable grows unbounded. The package currently offers no retention, pruning, or purging mechanism, leaving cleanup entirely to the consuming application.Proposal
Use Laravel's built-in pruning machinery instead of a custom command:
Illuminate\Database\Eloquent\MassPrunabletrait toApiLog.prunable()returning a builder scoped tocreated_at < now()->subDays(config('api-logs.prune_after_days')).prune_after_dayskey toconfig/api-logs.php, defaulting tonull(pruning disabled) so upgrading never silently deletes data.null,prunable()should match no rows.Consumers opt in by setting the config value and scheduling the framework command:
MassPrunableis preferred overPrunable: deletes run in chunked massDELETEqueries without hydrating models, which suits log data with no relationships to cascade or events to fire.Documentation
README should document the config key and the scheduler snippet, noting that a bare
model:pruneonly auto-discovers models inapp/Models, so the explicit--modeloption is required for package models.