Eloquent Cascade Laravel Package

Technical Evaluation

Architecture fit. The package targets a well-defined gap in Eloquent: application-level cascading for soft deletes, where database ON DELETE CASCADE cannot help because rows are only flagged, not removed. It integrates at the model layer via traits, which is idiomatic Laravel and requires no architectural change. That said, implicit cascade-on-delete is a domain rule living inside ORM lifecycle hooks; for a DDD-oriented or modular monolith it can obscure deletion semantics and make side effects hard to trace. Fit is strongest for conventional CRUD-style Laravel apps and weakest for systems with strict audit, retention, or regulatory deletion requirements.

Integration feasibility. Mechanically simple: composer require sofa/eloquent-cascade, add a trait, declare relations. The practical blocker is version compatibility. The last release (April 2021) predates Laravel 9/10/11, and Eloquent internals around SoftDeletes, model events, and forceDelete have shifted since. Expect a compatibility spike before any commitment.

Technical risk. Medium-to-high:

• Abandonment risk. 24 stars, 0 dependents, single maintainer, no release in ~4 years. Effectively unmaintained.
• Behavioral risk. Recursive deletion can produce long transactions, lock contention, N+1 queries, and recursion loops on circular relations.
• Semantic risk. Soft-delete cascade and restore are asymmetric; restoring a parent may not restore children. Force-delete behavior may differ from soft-delete behavior.
• Ordering risk. Conflicts with audit logging, observers, search indexing, and other packages that hook deleting/deleted.

Key questions for engineering.

• Which Laravel and PHP versions are actually supported, and does it run cleanly on our target version?
• Does it wrap cascades in a transaction, and is that transaction configurable?
• How does it behave on forceDelete, restore, and withTrashed relations?
• Is there recursion/depth protection for cyclic or self-referential relations?
• Does it cascade through belongsToMany pivot rows, or only hasMany/hasOne/morphMany?
• What is the query pattern and cost for a deletion graph of realistic depth and breadth?
• Is there a test suite we can run against our Laravel version?

Integration Approach

Stack fit. Only relevant if we are on Laravel/Eloquent and specifically need soft-delete cascades. For pure hard deletes, native foreign keys with onDelete('cascade') are more reliable, faster, and database-enforced; this package should not be used as a substitute there.

Migration path. Treat it as a candidate, not a default. Run a time-boxed spike on a branch: install, add traits to one low-risk model graph, and write tests covering soft delete, force delete, restore, transaction rollback, and cyclic relations. If it fails on our Laravel version, the options are (a) fork and pin internally under MIT, (b) vendor the trait into our codebase, or (c) implement explicit cascade logic in a service/observer layer. Given the size of the package, forking or vendoring is low-cost and removes upstream risk.

Compatibility. Verify against:

• Our Laravel and PHP versions, including composer.json constraints.
• Existing model observers and global scopes.
• Packages that hook deletion events (audit logs, activity feeds, search indexers).
• Database engine differences if we run multiple environments (MySQL/PostgreSQL/SQLite in tests).

Sequencing.

1. Inventory deletion semantics per model graph; classify soft vs. hard vs. archive.
2. Decide per graph: DB constraint, explicit service logic, or package trait.
3. Spike and test the package on the branch.
4. If adopted, fork/vendor and pin; add contract tests in CI.
5. Roll out graph-by-graph, lowest risk first, behind service-layer entry points.
6. Add monitoring for deletion latency, deadlocks, and orphaned rows.

Operational Impact

Maintenance. Assume we own it. Upstream is dormant; no security or compatibility patches should be expected. Budget for periodic review against Laravel upgrades. MIT licensing makes forking legally straightforward, which is the main mitigant.

Support. Community-only, thin community. No SLA, few Stack Overflow answers, and limited issue history. Internal documentation and tests become the real support surface. Ramp-up for a Laravel developer is low (a trait plus relation declarations), but understanding the failure modes is medium effort.

Scaling. Recursive application-level deletes scale worse than database cascades. Large graphs mean long-running transactions, row locks, replication lag, and potential timeouts. For high-volume or deep graphs, prefer asynchronous deletion jobs or database-level constraints where semantics allow. Soft-delete cascades also inflate table size and complicate purge jobs.

Failure modes.

• Partial deletion if cascades are not transactional, leaving orphaned or inconsistent records.
• Recursion loops or stack exhaustion on cyclic relations.
• Soft-deleted children under an active parent (or vice versa) after restore or partial failure.
• Silent divergence between soft-delete and force-delete behavior.
• Observer side effects firing in unexpected order (notifications, audit entries, index updates).
• Compatibility breakage after a Laravel upgrade with no upstream fix.

Recommendation. Not a default dependency. Approve for low-risk, conventional CRUD graphs after a compatibility spike, with the code forked or vendored and covered by tests. For hard deletes, use database foreign keys. For critical or regulated data, implement explicit deletion in the service layer where the semantics are visible, testable, and auditable.