Doctrine Cascade Soft Delete Bundle Laravel Package

Product Decisions This Supports

Core problem it addresses: soft delete is an UPDATE, so database-level ON DELETE CASCADE never fires. Soft-delete a parent and its children stay "live" in the database — still appearing in listings, counts, exports, and reports, and creating referential inconsistency your queries have to defend against forever. This package cascades the soft-delete through Doctrine associations at the application layer.

Decisions it informs:

• Whether soft delete belongs in this domain at all. If a feature needs audit trail, legal hold, or a recycle-bin UX, soft delete is the right call — but only if you also commit to a cascade strategy. This package is the "commit" half of that decision; adopting it (or building its equivalent) is the signal that soft delete is a first-class data pattern rather than a column bolted onto one model.
• Data-integrity strategy per bounded context. Three options: application-level cascade (this package), DB triggers, or hard delete with an immutable audit log. Cascade-at-the-ORM is usually the cheapest correct answer for Symfony/Doctrine shops; triggers are invisible to developers and fight with unit tests.
• Build vs. buy vs. ~100 lines of your own code. This problem is genuinely small: a Doctrine lifecycle listener or event subscriber plus association metadata gets you most of the way. The buy decision here is really "do we want a dependency, or do we want two days of engineering?" — and with 0 stars, 0 dependents, and a last release of February 2023, the honest answer leans toward internal implementation or a vendored fork.
• Roadmap scope for "delete" semantics. If a roadmap item says "users can delete a workspace/project/account," this is the dependency that determines whether child records vanish from the UI consistently or leak through. Scope the cascade work explicitly or it becomes a tail of correctness bugs filed one entity at a time.
• Vendor and stack fit (flag this early). The brief frames this as a Laravel/PHP package; it is not. It is a Symfony bundle built on Doctrine ORM. In a Laravel/Eloquent codebase it is unusable — Eloquent's SoftDeletes plus model-event cascadeDeletes (or a small observer) is the equivalent, and several maintained Laravel packages cover it. Confirming the framework before any evaluation is the single highest-value check a PM can make here.

When to Consider This Package

Consider it when:

• The stack is Symfony with Doctrine ORM (Symfony 5/6-era, PHP 8.x) and soft delete is used across multiple related entities.
• You have several parent-child or many-to-many associations where a soft-deleted parent must not leave live children — the cost of hand-writing listeners per entity is real and repetitive.
• Report, export, and count correctness matters — dashboards quietly over-reporting because children survived a parent delete is a credibility problem, not just a bug.
• You want the cascade behavior declared on the entity via annotation/attribute so it is visible at the model layer rather than buried in a service.
• You are comfortable vendoring or forking MIT code and owning it — which you should be, given the maintenance signals.

Look elsewhere when:

• The stack is Laravel/Eloquent. Wrong framework; use Eloquent SoftDeletes with model events, an observer, or a maintained Laravel cascade-soft-delete package.
• You are on a modern Symfony/Doctrine release and cannot verify compatibility. A bundle with zero dependents and no release since early 2023 has not been exercised against current Doctrine ORM or Symfony major versions; budget for a compatibility spike, or assume you are forking.
• The relation graph is simple — one or two parent-child pairs. Write the listener yourself; a dependency with no community around it is a worse liability than 80 lines you control and can unit test.
• You need hard-delete cascade, or mixed soft/hard semantics. That is DB-level ON DELETE CASCADE territory plus an audit table; this package does not simplify it.
• You require vendor support, SLAs, or a security review trail. Zero stars, zero dependents, single maintainer, no recent releases — this is a personal-scale library, not a supported component. Treat it as reference implementation and prior art, not as a dependency.

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: When we "delete" a record in this system we usually only hide it, so the database no longer removes the records that belonged to it. The result is that deleted projects, accounts, or workspaces keep contributing rows to reports, counts, and exports — numbers quietly drift and support gets tickets about data that should be gone. This package makes that cleanup automatic and consistent. It is a small, unmaintained open-source library with no adoption, so the recommendation is not to depend on it — the recommendation is to treat it as a specification for roughly two days of our own engineering. Low cost, removes a whole class of correctness bugs, no vendor risk.

To engineering — the practical framing: It is a Symfony/Doctrine bundle that hooks entity lifecycle events and propagates soft-delete to configured associations, because FK cascade constraints do not fire on UPDATE. It is exactly the right shape for our problem. It is also a one-person project, last released Feb 2023, no dependents, no CI signal we can verify against our Symfony/Doctrine versions. Proposal: do not add it to composer.json. Read it, use its attribute-driven API as the design, and implement the listener in-house against our own Doctrine version — with tests covering every association we soft-delete. If we later find ourselves reimplementing more than expected, we revisit a vendored fork with a named internal owner.

To the team as a product signal: The fact that this package exists, is MIT, and has essentially no users is informative in itself: cascade soft delete is a well-known sharp edge that almost nobody solves with a dependency. Plan for it as engineering work inside any "delete" feature, not as a library selection.