Mongodb Odm Softdelete Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Legacy Symfony2 Dependency: The package is explicitly tied to Symfony 2.0.x and Doctrine MongoDB ODM, which may not align with modern Laravel/PHP ecosystems (Laravel uses Eloquent or other ORMs by default). The bundle’s architecture assumes a Symfony2 + Doctrine ODM stack, making direct adoption in Laravel impractical without significant abstraction.
• Soft-Delete Pattern: The core functionality (soft-deletion via a deletedAt field) is a well-established pattern in Laravel (via SoftDeletes trait in Eloquent). However, the implementation is ODM-specific, requiring MongoDB integration.
• Bundle vs. Composer: The package is a Symfony bundle, not a standalone Composer package, complicating integration into Laravel’s service container and routing system.

Integration Feasibility

• MongoDB ODM in Laravel: Laravel’s default ORM is Eloquent (SQL), not ODM. Integrating Doctrine ODM would require:
  • Replacing Eloquent with ODM (breaking change).
  • Managing two ORMs (Eloquent for SQL, ODM for MongoDB), increasing complexity.
  • Potential conflicts with Laravel’s service providers, service container, and query builder.
• Alternative Approaches:
  • Use Laravel’s native SoftDeletes for SQL databases.
  • For MongoDB, consider Jenssegers/MongoDB (a Laravel-compatible MongoDB driver) with custom soft-delete logic.
  • Use Doctrine MongoDB ODM in a microservice alongside Laravel (not monolithic).

Technical Risk

• High Integration Risk:
  • Symfony2 vs. Laravel: The bundle’s assumptions (e.g., appKernel.php, deps file) are incompatible with Laravel’s composer.json and config/app.php.
  • ODM vs. Eloquent: Doctrine ODM’s query syntax (e.g., Criteria, QueryBuilder) differs from Eloquent, requiring rewrites.
  • No Active Maintenance: The package is archived, with no updates for Symfony 3+ or Laravel. Risk of breaking changes in dependencies (e.g., Doctrine ODM).
• Functional Gaps:
  • No support for Laravel’s event system (e.g., deleting model events).
  • No integration with Laravel’s query scopes or accessors/mutators.
• Performance Overhead:
  • ODM’s soft-delete implementation may not optimize for Laravel’s caching (e.g., model events, query caching).

Key Questions

1. Why MongoDB ODM?
   • Is MongoDB a hard requirement, or could SQL (with SoftDeletes) suffice?
   • If MongoDB is needed, is Jenssegers/MongoDB (with custom soft-delete logic) a viable alternative?
2. Legacy Constraints:
   • Is Symfony2 compatibility a blocker? Could a modern fork (e.g., Symfony 5/6 + Laravel bridge) be created?
3. Maintenance Burden:
   • Who would maintain this integration long-term? The original package is abandoned.
4. Alternatives Evaluated:
   • Has Laravel’s SoftDeletes or custom MongoDB soft-delete logic been considered?
   • Are there modern Laravel MongoDB packages (e.g., spatie/laravel-mongodb) that support soft deletes?
5. Migration Path:
   • What’s the fallback if this integration fails (e.g., hard deletes, separate service)?

Integration Approach

Stack Fit

• Incompatible Stack:
  • Laravel (PHP 8.x, Eloquent, Composer) vs. Symfony2 (PHP 5.4–5.6, Doctrine ODM, deps).
  • The bundle’s Symfony-specific components (e.g., Bundle, Kernel) cannot be directly ported to Laravel.
• Workarounds:
  1. Hybrid Architecture:
     • Use Doctrine ODM in a separate microservice (e.g., via API) while Laravel handles SQL.
     • Example: Laravel calls a Symfony API for MongoDB operations.
  2. Custom Laravel Wrapper:
     • Extract the soft-delete logic from the bundle (e.g., SoftDeleteable trait) and adapt it for Laravel’s MongoDB driver (e.g., jenssegers/mongodb).
     • Example:

       use Jenssegers\Mongodb\Eloquent\Model as MongoModel;
       
       class Post extends MongoModel {
           use \Doctrine\ODM\MongoDB\SoftDelete\SoftDeleteable; // Hypothetical port
           protected $deletedField = 'deleted_at';
       }
       

  3. Feature Parity:
     • Reimplement soft-delete in Laravel using MongoDB’s $natural or $currentDate operators in queries.

Migration Path

Compatibility

• Doctrine ODM Version:
  • The bundle targets old Doctrine ODM versions (likely pre-1.0). Modern ODM (2.x) may have breaking changes.
• MongoDB Driver:
  • Laravel’s jenssegers/mongodb uses PHP MongoDB driver, while ODM uses Doctrine’s MongoDB client. Query syntax may differ.
• Symfony Dependencies:
  • The bundle relies on Symfony’s EventDispatcher, which Laravel replaces with its own system.

Sequencing

1. Phase 1: Proof of Concept
   • Test soft-deletes with jenssegers/mongodb + custom logic (no bundle).
   • Validate queries like:

     Post::whereNull('deleted_at')->get(); // Active records
     

2. Phase 2: Bundle Integration (if viable)
   • Fork the bundle, remove Symfony dependencies, and adapt for Laravel.
   • Example: Replace Bundle with a Laravel Service Provider.
3. Phase 3: Full Migration
   • Replace all model queries to use soft-delete logic.
   • Update APIs, jobs, and cron tasks to respect deleted_at.

Operational Impact

Maintenance

• High Ongoing Effort:
  • No upstream support: The original package is archived. Any fixes or updates must be maintained in-house.
  • Dependency Hell:
    • Doctrine ODM and Symfony2 dependencies may conflict with Laravel’s PHP version (e.g., PHP 8.x compatibility).
    • Example: ODM may require PHP 7.4, while Laravel supports 8.0+.
  • Dual ORM Complexity:
    • Managing Eloquent (SQL) + ODM (MongoDB) increases:
      • Query complexity (e.g., joins vs. embedded documents).
      • Migration risks (e.g., schema changes in both databases).

Support

• Debugging Challenges:
  • Stack Trace Mismatches: Errors from ODM/Symfony2 may not align with Laravel’s error handling.
  • Limited Community: Few resources for troubleshooting Laravel + Doctrine ODM issues.
• Vendor Lock-in:
  • Custom integration may become hard to replace if abandoned.

Scaling

• Performance Bottlenecks:
  • ODM Overhead: Doctrine ODM’s hydration and query building may be slower than Eloquent.
  • Soft-Delete Queries: Adding whereNull('deleted_at') to every query increases indexing requirements on deleted_at.
• Horizontal Scaling:
  • MongoDB Sharding: ODM’s soft-delete behavior must align with shard keys.
  • Cache Invalidation: Soft-deletes may require cache tag invalidation (e.g., post:{{id}}:deleted).

Failure Modes