Db Safedelete Laravel Package

Technical Evaluation

Architecture fit

• The package is a micro-behavior layer over Eloquent's SoftDeletes, not an architectural component. It overrides the deletion path on a model so that a caller-issued "hard delete" degrades to a soft delete when the database rejects the hard delete (typically an FK RESTRICT/NO ACTION violation).
• It only fits models that satisfy both preconditions: the table has a deleted_at column and uses SoftDeletes, and there is a real business case where some rows are orphaned (safe to purge) while others are referenced (must be retained). That is a narrow band — most models are either always-soft-delete or always-hard-delete.
• Where it does fit, it is a pragmatic alternative to hand-rolling "check for children, then branch" logic in every service method. It centralizes the decision at the persistence boundary, which is the correct layer.
• It is a poor fit for domains with regulatory erasure requirements (GDPR/CCPA right-to-be-forgotten): a silent fallback means "delete" does not mean delete, and the caller has no explicit signal.

Integration feasibility

• Installation is trivial (Composer + a trait on the model). No config, no migrations, no service provider surface implied. Engineering cost is measured in hours, not sprints.
• The real feasibility question is framework version support. This is a small, low-velocity package (16 stars, score 0.08) whose trait depends on internal Eloquent method signatures and QueryException shape. Verify it against your Laravel major (10/11/12) before committing; expect to vendor or fork if it predates your version.
• The behavior is a ~30–100 LOC concern. Reimplementing it first-party is cheap and removes the dependency entirely — a legitimate option for a TPM to put on the table.

Technical risk

• Transactional integrity on PostgreSQL (highest risk). A failed statement inside an open transaction aborts the entire transaction (25P02 current transaction is aborted). If the implementation catches the FK exception and then issues the soft UPDATE in the same transaction, it will fail on Postgres. It needs SAVEPOINT/savepoint semantics to be portable. MySQL/InnoDB tolerates this pattern; Postgres does not. Validate the engine before designing around it.
• Event and audit duplication. forceDeleting/forceDeleted may fire before the fallback, then deleting/deleted fire. Observers, audit logs, activity feeds, webhooks, and queued listeners will see two deletion intents for one user action. This is the most likely source of production incidents.
• Silent degradation is a data-governance hazard. Rows the business believes are purged remain on disk indefinitely. Retention jobs, PII scans, and storage-growth forecasts all become wrong unless the fallback emits a metric.
• Ambiguous contract. Callers get a boolean that means "something was deleted," not "which thing." Callers who need certainty must re-query trashed(), which is a race unless inside the same transaction.
• Cascade interaction. Models with $touches, cascadeOnDelete FKs, or application-level child cleanup may execute cleanup logic on the failed path and then again on the fallback path.
• License is NOASSERTION. This is a hard gate for most legal/procurement processes. It may just be a missing LICENSE file alongside an MIT declaration in composer.json, but it must be resolved in writing before adoption.

Key questions

1. Which database engines must we support, and does the fallback work correctly on Postgres inside an existing transaction?
2. What is the package's tested Laravel/PHP matrix, and is the maintainer responsive to version bumps?
3. What is the actual license, and will legal accept it?
4. For each candidate model, is "delete" a user-facing promise of erasure or an internal lifecycle transition? Only the latter tolerates silent fallback.
5. Do we need an explicit signal (return enum, event, log/metric) distinguishing hard-delete from soft-delete for downstream consumers?
6. Is 16 stars / one maintainer acceptable for code we could own outright in a day?

Integration Approach

Stack fit

• Requires Laravel + Eloquent, a deleted_at column, and the SoftDeletes trait on each participating model. No queue, cache, or storage dependency.
• Best suited to internal/admin-panel backends where an operator clicks "delete" and the system should remove what it safely can. Poor fit for customer-facing APIs with documented hard-delete semantics.
• Fits cleanly alongside existing policy/authorization layers; it changes how a delete resolves, not whether it is permitted.

Migration path

• Do not retrofit this onto existing delete paths globally. Introduce it per-model, starting with a single low-traffic, low-blast-radius entity.
• For legacy code, keep existing explicit branching until each model has been observed in production under the new behavior.
• Where a service already knows the record is referenced (it queried children), keep the explicit softDelete(). The package adds value only for callers that genuinely cannot know in advance.
• Add a fallback counter/log line at adoption time so the fallback path is observable from day one; without it you cannot tell whether the feature is working or merely never exercised.

Compatibility

• Laravel version: confirm against your major version; be prepared to vendor the trait into app/ and drop the dependency.
• Database: MySQL/MariaDB are the safe target. PostgreSQL requires savepoint handling — test explicitly. SQLite only enforces FKs when PRAGMA foreign_keys=ON; behavior will differ between test and production. SQL Server's error codes differ from MySQL's 23000, so any string/errno-based exception matching must be engine-aware.
• Transactions: verify behavior both standalone and nested inside an application transaction, and inside DB::transaction() closures.
• Events: inventory every observer, model event listener, and queued job attached to the candidate models before enabling.

Sequencing

1. Legal/license clearance — blocking gate; resolve before engineering effort.
2. Engine + Laravel compatibility spike — one spike branch, one model, both MySQL and Postgres, transactional and non-transactional paths.
3. Fork-or-depend decision — if the spike is clean, depend; if not, copy the trait in-repo (preferred given the size and the license ambiguity).
4. Instrument — fallback metric, structured log with model/ID/constraint, alert on unexpected volume.
5. Pilot — one internal model, one release cycle, review audit-log output for duplicate events.
6. Expand — model by model, with the event/observer review repeated each time.

Operational Impact

Maintenance

• Near-zero runtime maintenance but non-trivial dependency maintenance: an unmaintained third-party trait that reaches into Eloquent internals will break on a future Laravel major. Given the package's size and signal (16 stars, 0.08 score), vendoring the trait into the codebase is the recommended posture — you get the behavior, you own the upgrade, and the license question disappears.
• Budget roughly half a day to reimplement and unit-test if you go first-party. Ongoing cost is then folded into normal model maintenance.

Support

• No vendor, no SLA, no security-response process. Community issue tracker only.
• Internal support burden falls on whoever owns the data layer. Document the fallback semantics in the model's docblock and in the team runbook — future engineers will otherwise assume delete() means delete.
• The NOASSERTION license creates a procurement/compliance follow-up that will resurface at every audit if not documented.

Scaling

• Negligible performance cost in the normal case. In the fallback case, every "delete" attempt issues a failing DELETE (index/FK check work) followed by an UPDATE — roughly 2× the statement count on affected rows.
• Under contention, a failing DELETE still takes locks on the parent row and referenced indexes. High-volume bulk deletion of heavily-referenced parents can produce lock-wait and deadlock exposure that would not exist with an explicit soft delete upfront.
• For bulk operations (Model::where(...)->delete()), verify the trait is even engaged — mass deletes bypass model events and may not route through the fallback. This is a likely blind spot.

Failure modes

• Postgres aborted transaction — fallback throws, caller sees an error, nothing is deleted. Highest severity, cleanest to detect.
• Silent retention — hard delete never succeeds, rows accumulate; storage and retention-policy drift go unnoticed until an audit or a cost review. Highest likelihood.
• Duplicate audit events — compliance logs record two deletions for one action; corrupts deletion reporting.
• Partial cascade — child cleanup runs, parent delete fails to hard-delete, state is left soft-deleted mid-cascade depending on transaction boundaries.
• Unintended hard delete — the inverse risk: a row the business expected to retain (because it looked referenced) is in fact unreferenced and is destroyed. This is why the fallback must be paired with an explicit retention policy, not relied on as one.
• Test/production divergence — SQLite tests pass because FKs are off; production MySQL enforces them.

Ramp-up

• Developer ramp-up: low. Any Laravel developer understands the trait in minutes.
• Correct usage ramp-up: medium. The team must internalize that this is a fallback mechanism, not a retention policy, and that the return value is not a guarantee of erasure.
• Operational ramp-up: medium. On-call needs a runbook entry covering what a spike in fallback metrics means and how to reconcile soft-deleted rows against the retention schedule.
• Stakeholder ramp-up: essential. Product, legal, and data-governance must sign off explicitly that "delete" is best-effort for the affected entities — this is the single decision most likely to be regretted later.