Laravel Deleted Models Laravel Package

Technical Evaluation

Architecture Fit

• Soft Deletes Alternative: Fits well in Laravel applications requiring a recycle bin pattern (beyond Laravel’s native SoftDeletes). Ideal for compliance, auditing, or temporary data retention needs.
• Separation of Concerns: Maintains original model integrity while offloading deleted records to a dedicated table (deleted_models), reducing clutter in the primary database.
• Query Flexibility: Supports querying deleted records via DeletedModel::where() or restoring via Model::restore(), enabling custom recovery logic.

Integration Feasibility

• Laravel Native: Leverages Eloquent events (deleting) and model traits (HasDeletedModels), requiring minimal customization.
• Database Agnostic: Works with any database supported by Laravel (MySQL, PostgreSQL, SQLite, etc.).
• Schema Requirements: Automates migration creation for deleted_models table, but requires manual adjustments for complex relationships or custom attributes.

Technical Risk

• Performance Overhead:
  • Write Operations: Copying model attributes on delete() adds latency (mitigated by batching or async processing if needed).
  • Storage Bloat: Prolonged retention of deleted records may inflate database size (address via TTL policies or cleanup jobs).
• Data Consistency:
  • Relationships: Child models deleted via cascades won’t auto-copy (requires manual handling or additional logic).
  • Events/Observers: Custom deleting logic may conflict with package hooks.
• Testing:
  • Edge Cases: Requires validation for large payloads, nested deletes, or concurrent operations.

Key Questions

1. Retention Policy: How long should deleted records persist? (Affects cleanup strategy.)
2. Relationship Handling: Are child models deleted via cascades? If so, how to preserve their state?
3. Concurrency: How to handle race conditions during delete()/restore() operations?
4. Custom Attributes: Does the package support non-serializable attributes (e.g., JSON, polymorphic relations)?
5. Backup Impact: Will deleted_models table require inclusion in backups? If so, how to optimize storage?
6. Audit Trails: Does the package integrate with logging (e.g., Laravel’s logging channel) for compliance?

Integration Approach

Stack Fit

• Laravel Ecosystem: Optimized for Laravel 10+ (PHP 8.1+), with compatibility back to Laravel 8.
• Dependencies:
  • Requires spatie/laravel-model-states (included as a sub-dependency) for state management.
  • No external services; pure database-driven.
• Testing: CI/CD pipelines include PHPUnit tests (90%+ coverage), reducing integration risk.

Migration Path

1. Installation:

   composer require spatie/laravel-deleted-models
   php artisan vendor:publish --provider="Spatie\DeletedModels\DeletedModelsServiceProvider"
   php artisan migrate
   

2. Model Integration:
   • Apply HasDeletedModels trait to target models:

     use Spatie\DeletedModels\HasDeletedModels;
     
     class BlogPost extends Model
     {
         use HasDeletedModels;
     }
     

   • Optional: Customize deleted_models table name or attributes via trait configuration.
3. Testing:
   • Unit tests for delete()/restore() workflows.
   • Load tests for high-volume deletion scenarios.

Compatibility

• Existing SoftDeletes: Conflicts if models use SoftDeletes trait (mutually exclusive). Requires refactoring.
• Custom Delete Logic: Override delete() method if additional logic (e.g., notifications) is needed.
• Third-Party Packages: May interfere with packages hooking into deleting events (e.g., audit logs). Use middleware or event prioritization.

Sequencing

1. Phase 1: Pilot with non-critical models (e.g., drafts, logs).
2. Phase 2: Integrate core models, testing restore functionality.
3. Phase 3: Implement cleanup policies (e.g., scheduled purges via Spatie\DeletedModels\PurgeDeletedModels).
4. Phase 4: Monitor performance and adjust indexing/TTL as needed.

Operational Impact

Maintenance

• Package Updates: MIT license allows easy upgrades; Spatie maintains active development (last release: 2026-03-06).
• Customization:
  • Extend via DeletedModel model events (deleted, restored).
  • Override getDeletedModelAttributes() for custom attribute handling.
• Documentation: Comprehensive README and changelog; community-driven support via GitHub issues.

Support

• Debugging:
  • Log deleted_models table growth and query performance.
  • Use DB::enableQueryLog() to trace attribute copying delays.
• Fallbacks:
  • Implement manual backup/restore procedures for critical data.
  • Add admin UI for bulk restoration/deletion.

Scaling

• Performance:
  • Indexing: Add indexes to deleted_models.deleted_at and deleted_models.model_type for large datasets.
  • Batch Processing: Use queue workers (delete() events) for high-throughput systems.
  • Archiving: Offload old records to cold storage (e.g., S3) via custom jobs.
• Database Load:
  • Monitor deleted_models table size; set soft limits (e.g., purge records >30 days old).

Failure Modes

Ramp-Up

• Developer Onboarding:
  • 1-hour workshop on trait usage, restore patterns, and cleanup jobs.
  • Documentation snippet for common use cases (e.g., restoring with related models).
• QA Checklist:
  • Verify delete() copies all required attributes.
  • Test restore with nested relationships.
  • Validate cleanup jobs don’t affect active data.
• Rollback Plan:
  • Drop deleted_models table and revert trait usage if issues arise.
  • Maintain a shadow database for critical data during pilot.