Mongodb Odm Softdelete Laravel Package

Technical Evaluation

Architecture Fit

• Use Case Alignment: The package provides soft delete functionality for MongoDB ODM, which is a critical feature for applications requiring data retention without physical deletion (e.g., compliance, auditing, or reversible actions).
• Doctrine ODM Compatibility: If the system already uses Doctrine MongoDB ODM, this package integrates natively, reducing boilerplate for soft-delete logic (e.g., isDeleted, deletedAt fields, lifecycle callbacks).
• MongoDB-Specific Advantages: Leverages MongoDB’s native query capabilities (e.g., $and with deletedAt: null) for efficient filtering, avoiding full-table scans.
• Potential Overhead: Adds a query layer complexity (e.g., ensuring all queries include the soft-delete filter) and storage overhead (extra deletedAt field per document).

Integration Feasibility

• High for ODM Users: Minimal changes required if already using Doctrine MongoDB ODM (e.g., annotate entities with @SoftDeleteable).
• Low for Non-ODM Systems: Requires adopting Doctrine ODM or manually implementing soft-delete logic elsewhere.
• Migration Risk: If the system uses raw MongoDB drivers or other ORMs, integration effort increases significantly.

Technical Risk

• Query Performance: Incorrectly scoped queries (e.g., forgetting to filter deletedAt) could return soft-deleted records, leading to data leaks.
• Schema Changes: Requires adding deletedAt field to all relevant collections, which may need backward-compatible migration strategies.
• Concurrency Issues: Race conditions possible if deletedAt updates aren’t atomic (though Doctrine ODM typically handles this).
• Testing Gaps: Archived status suggests limited maintenance; may lack support for newer Doctrine ODM versions or MongoDB features.

Key Questions

1. Current Data Model: Are collections already using Doctrine ODM, or would this require a full ORM migration?
2. Query Patterns: How are queries currently structured? Will they need widespread updates to include soft-delete filters?
3. Compliance/Audit Needs: Is soft delete required for all entities, or only specific ones (e.g., user data vs. logs)?
4. Performance Impact: What’s the expected volume of soft-deleted records? Could this bloat queries or indexes?
5. Alternative Solutions: Are there existing soft-delete implementations (e.g., custom middleware, MongoDB’s $redact) that could avoid ODM dependency?

Integration Approach

Stack Fit

• Primary Fit: Systems using Doctrine MongoDB ODM (PHP 8.x, Laravel with DoctrineBundle, or standalone ODM).
• Secondary Fit: Projects willing to adopt ODM for this feature (e.g., legacy systems migrating to a more structured data layer).
• Non-Fit: Systems using:
  • Raw MongoDB drivers (PHP mongodb extension).
  • Other ORMs (e.g., Eloquent, Propel).
  • Non-PHP stacks (Node.js, Python, etc.).

Migration Path

1. Assessment Phase:
   • Audit existing queries to identify where soft-delete filters are needed.
   • Verify Doctrine ODM version compatibility (package may not support latest ODM).
2. Schema Update:
   • Add deletedAt field (DateTime) to all relevant collections via migration.
   • Example:

     use Doctrine\ODM\MongoDB\Mapping\Annotations as MongoDB;
     
     /** @MongoDB\Document */
     class User {
         /** @MongoDB\Field(type="date") */
         public $deletedAt;
     }
     

3. Entity Configuration:
   • Annotate entities with @SoftDeleteable and configure deletedAt field.
   • Example:

     use Doctrine\ODM\MongoDB\Mapping\Annotations as MongoDB;
     
     /** @MongoDB\SoftDeleteable(fieldName="deletedAt") */
     class User { ... }
     

4. Query Layer Updates:
   • Ensure all repository queries use find() or createQueryBuilder() with soft-delete filters.
   • Example (QueryBuilder):

     $qb = $this->createQueryBuilder('u')
         ->where('u.deletedAt = null');
     

5. Application Logic:
   • Update CRUD operations to trigger soft deletes (e.g., softDelete($user) instead of remove($user)).
   • Example:

     $dm->softDelete($user); // Sets deletedAt to now()
     

Compatibility

• Doctrine ODM Version: Check compatibility with the project’s ODM version (e.g., 1.3.x vs. 2.0+).
• MongoDB Driver: Requires PHP MongoDB driver (extension or mongodb library).
• PHP Version: Likely requires PHP 7.4+ (align with Doctrine ODM’s support).
• Archived Status: May lack updates for new MongoDB features (e.g., change streams, transactions).

Sequencing

1. Low-Risk Pilot: Test on a non-critical collection first (e.g., logs or test data).
2. Query Validation: Verify soft-delete filters work in all read paths (APIs, admin panels, reports).
3. Performance Testing: Measure impact on query speed and index usage.
4. Rollback Plan: Document steps to revert deletedAt field if needed (e.g., via migration).

Operational Impact

Maintenance

• Dependency Risk: Archived package may require forks or manual patches for long-term use.
• Documentation Gaps: Lack of updates could lead to undocumented breaking changes.
• Upgrade Path: No clear roadmap; may need to maintain a local fork or switch to alternatives (e.g., stof/doctrine-extensions).
• Community Support: Limited to GitHub issues; no official channels.

Support

• Debugging Challenges: Soft-delete issues (e.g., missed filters) may be subtle and hard to trace.
• Tooling Integration: May not work seamlessly with:
  • MongoDB Compass (manual filtering needed).
  • Doctrine migrations (custom logic for deletedAt).
• Monitoring: Requires alerts for:
  • Queries bypassing soft-delete filters.
  • Unusually high deletedAt updates (potential abuse).

Scaling

• Indexing: Ensure deletedAt is indexed to avoid performance degradation on large collections.

  /** @MongoDB\Index(keys={"deletedAt"="asc"}) */
  

• Query Optimization: Complex queries with soft-delete filters may benefit from MongoDB’s explain() analysis.
• Storage Growth: Soft-deleted records still consume space; consider TTL indexes for auto-purging old entries:

  $collection->createIndex(['deletedAt' => 1], ['expireAfterSeconds' => 2592000]); // 30 days
  

Failure Modes

Ramp-Up

• Developer Onboarding:
  • Document soft-delete conventions (e.g., "always use softDelete()").
  • Train teams on QueryBuilder usage to avoid raw queries.
• Testing Strategy:
  • Unit tests for soft-delete logic in repositories.
  • Integration tests for critical read paths.
• Performance Baseline:
  • Measure query times before/after integration.
  • Set alerts for regression (e.g., queries > 500ms).
• Rollout Phases:
  1. Phase 1: Backend services only (no UI changes).
  2. Phase 2: Admin panels (add "Restore" functionality).
  3. Phase 3: Public APIs (ensure filters are applied client-side).