Doctrine Garbage Collection Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Purpose Alignment: The bundle is a Doctrine ORM garbage collection tool, targeting stale/obsolete entity data (e.g., soft-deleted records, orphaned relations, or expired cache). This aligns well with data-health initiatives in Laravel/Symfony ecosystems where:
  • Symfony apps (especially legacy or high-transaction systems) suffer from bloat in DB tables (e.g., deleted_at records, unreferenced entities).
  • Laravel apps using Doctrine DBAL or Symfony bridges (e.g., symfony/doctrine-bridge) could benefit from automated cleanup.
• Design Philosophy:
  • Declarative: Config-driven (YAML/XML) for defining cleanup rules (e.g., TTL, orphaned relations).
  • Event-Driven: Hooks into Doctrine lifecycle (e.g., postFlush, postCommit) for real-time or scheduled cleanup.
  • Extensible: Supports custom collectors via PSR-15 middleware or Symfony events.
• Anti-Patterns:
  • Not for hard deletes: Focuses on soft deletes/garbage (not primary key purges).
  • Doctrine-centric: Requires Doctrine ORM (not Eloquent-native; Laravel would need a bridge).

Integration Feasibility

• Symfony Ecosystem:
  • Native Fit: Designed for Symfony 5.4+/6.x with DoctrineBundle. Minimal boilerplate if using Symfony’s dependency injection.
  • Bundle Compatibility: Works with doctrine/orm (v2.10+), doctrine/doctrine-bundle, and symfony/messenger (for async cleanup).
• Laravel Adaptation:
  • Challenges:
    • Laravel’s Eloquent ORM lacks Doctrine’s event system. Would require:
      • Middleware/Service Provider: Wrap Doctrine DBAL events (e.g., postInsert, postUpdate) to mimic Symfony’s postFlush.
      • Custom Collector: Extend GarbageCollectionCollectorInterface for Eloquent models.
    • No Native Bundle Support: Laravel’s Bundle system is nonexistent; would need a standalone package (e.g., laravel-doctrine-garbage-collection).
  • Workarounds:
    • Use Doctrine DBAL directly in Laravel (if already in stack) to leverage the bundle’s core logic.
    • Hybrid Approach: Run cleanup via Laravel Scheduler + Symfony Console Component (if Symfony is a dependency).

Technical Risk

Key Questions

1. Is Doctrine ORM a mandatory dependency, or can we use DBAL-only mode for Laravel?
2. What’s the cleanup priority?
   • Real-time (post-save) vs. batch (scheduled cron)?
   • Critical for performance (e.g., deleted_at bloat) or non-urgent (e.g., audit logs)?
3. How will we handle conflicts?
   • E.g., concurrent writes during garbage collection.
4. What’s the fallback for unsupported Laravel features?
   • Example: Symfony’s PostCommitEvent → Laravel’s queue:work + Model::booted().
5. Will we need custom collectors?
   • If so, how will we document the extension points for the team?

Integration Approach

Stack Fit

Migration Path

1. Symfony (Native):

   • Step 1: Install via Composer:

     composer require 22h/doctrine-garbage-collection-bundle
     

   • Step 2: Enable in config/bundles.php and define collectors in config/packages/doctrine_garbage_collection.yaml.
   • Step 3: Test with php bin/console doctrine:garbage-collection:run.
   • Step 4: Integrate with Symfony’s scheduler (e.g., cron or symfony/clock).

2. Laravel (Adapted):

   • Option A: DBAL-Only (Lowest Risk):
     • Install Doctrine DBAL:

       composer require doctrine/dbal
       

     • Fork the bundle’s core logic into a Laravel package (e.g., vendor/bin/garbage-collector).
     • Use Laravel’s Model::registerGlobalScopes() to hook into deleted_at queries.
   • Option B: Full Integration (Higher Risk):
     • Create a Laravel wrapper package (e.g., spatie/laravel-doctrine-garbage-collection).
     • Implement:
       • GarbageCollectionServiceProvider to bootstrap Doctrine events.
       • GarbageCollectionFacade for Artisan commands.
       • Custom EloquentCollector extending the bundle’s interface.
     • Example:

       // app/Providers/GarbageCollectionServiceProvider.php
       public function boot()
       {
           Model::registerGlobalObserver(new GarbageCollectionObserver());
       }
       

Compatibility

• Doctrine Version:
  • Bundle requires Doctrine ORM 2.10+ (Symfony 5.4+) or DBAL 2.10+.
  • Laravel’s doctrine/dbal (v3.x) is compatible; Eloquent requires no changes to core logic.
• PHP Version:
  • Bundle supports PHP 8.0+; Laravel’s minimum (8.0+) aligns.
• Database Support:
  • Works with any Doctrine-supported DB (MySQL, PostgreSQL, SQLite, etc.).
  • No Laravel-specific DB quirks (e.g., MySQL’s ON DELETE CASCADE is handled by Doctrine).

Sequencing

1. Phase 1: Proof of Concept (2 weeks)
   • Symfony: Test bundle in staging with a non-critical table (e.g., audit_logs).
   • Laravel: Implement DBAL-only mode and validate cleanup logic.
2. Phase 2: Core Integration (3 weeks)
   • Symfony: Configure collectors for all soft-deleted entities.
   • Laravel: Build wrapper package with Artisan command and observer hooks.
3. Phase 3: Optimization (1 week)
   • Benchmark performance (e.g., 10K records/hour cleanup rate).
   • Add async support (Symfony Messenger / Laravel Queues).
4. Phase 4: Rollout
   • Symfony: Deploy to production with monitoring (e.g., log cleanup events).
   • Laravel: Publish package to Packagist and document migration steps.

Operational Impact

Maintenance

• Symfony:
  • Pros:
    • Minimal maintenance; bundle is batteries-included (config, CLI, events).
    • Updates align with Doctrine/Symfony releases.
  • Cons:
    • YAML config may require refactoring if entity structure changes.
• Laravel:
  • Pros:
    • Custom package can abstract Doctrine complexity behind a simple facade.
    • Leverages Laravel’s service container for easy dependency injection.
  • Cons:
    • Custom codebase requires long-term ownership (e.g., fixing Doctrine version skew).
    • Testing overhead: Need to validate cleanup logic for all Eloquent models.

Support

• Symfony:
  • Community: Limited (0