Disable Orm Bundle Laravel Package

Product Decisions This Supports

• Stack-fit triage (the decision that comes first): despite the "Laravel/PHP package" framing, this is a Symfony + Doctrine ORM bundle. It works by swapping doctrine.orm.entity_managers.<name>.class_metadata_factory_name, ships Symfony bundle registration (config/bundles.php), and has no Eloquent equivalent. A Laravel-only roadmap gets zero value from it; a Symfony/Doctrine service gets a narrow but real capability. Confirm stack before anything else — this is the cheapest and most important call.
• Turning column removal into a repeatable "expand / contract" release pattern: tag a property #[DisableORM], ship the release that ignores it, then drop the column in a follow-up migration. Old and new instances can run against the same database during a rolling deploy. This converts a synchronized all-hands migration event into two ordinary deploys — a release-engineering capability, not a feature.
• Removing maintenance windows from the roadmap: the README's own motivation is the PM-level pain — with multiple versions live, modifying an entity forces a shutdown-and-migrate. Buying this lets you stop scheduling downtime for schema cleanup and stop gating releases on migration coordination.
• Prioritizing schema debt paydown: teams defer dropping dead columns because it's risky. Lowering that risk raises the ROI of cleanup work, so a "deprecate and drop N legacy columns this quarter" initiative becomes plannable instead of perpetually deprioritized.
• Build vs. buy is genuinely cheap either way: the core is a Doctrine ClassMetadataFactory override plus an attribute — plausibly a few hundred lines in-house. The differentiators worth paying attention to are the guardrails: a configurable disable_on_commands allowlist (defaults keep doctrine:schema:validate and doctrine:migrations:diff seeing the field so migrations can still target it), a PHPStan rule for entity misuse, and a CI git-diff script that fails builds when a field is deleted without first being #[DisableORM]-flagged. That CI check is arguably the real product — it prevents the one mistake that would otherwise turn this into an outage generator.
• Concrete use cases to scope against: rolling / blue-green / canary deploys; monoliths with long-lived databases; removing columns owned by a deprecated feature; sunsetting a legacy subsystem while the old version drains; multi-tenant or multi-region fleets where instances can't flip in lockstep.
• What it explicitly does not buy you: no field addition or modification support, no dynamic or reversible toggling, no ORM access to a disabled field (raw SQL only), and no protection from your own missing read paths. Any roadmap item premised on "flip a field back on at runtime" is out of scope.

When to Consider This Package

Adopt when all of these hold:

• Symfony with Doctrine ORM (Doctrine bundle 3 / Symfony 7.4–8 per the 1.1.0 release), PHP 8+, and a real Doctrine EntityManager.
• You genuinely run multiple application versions against one database at the same time, or you can't tolerate a migration-then-deploy gap.
• Your schema-change need is specifically column removal — the contract step of expand/contract.
• You can set a DB-level default on a field before disabling it (the README calls this out; without it, inserts on newer instances can break).
• You can own the setup cost: register the bundle, override class_metadata_factory_name per entity manager, and wire the PHPStan include plus the CI change-detection script into the pipeline.
• You're willing to test the consumers of ORM metadata — repositories, SELECT *-style query builders, hydrators, and any admin/API layer (EasyAdmin, API Platform, Gedmo/Stof-style extensions) that introspects mappings.

Look elsewhere — or don't adopt — when:

• You're on Laravel or Eloquent. Wrong framework; use Laravel's own expand/contract migration practice. This is the disqualifier most likely to apply here.
• Deploys are atomic and version-locked (single instance, or you can always drain old workers). The bundle buys nothing and adds a metadata factory you now maintain.
• You need reversible behavior, per-environment toggles, or runtime field enable/disable. This is a one-way, compile-time-style removal.
• Any code path must keep using the field through the ORM after disabling — you'd need to rewrite to raw SQL, usually a downgrade.
• Maintenance risk is unacceptable. Zero stars, zero dependents, single maintainer. MIT plus a small surface area caps the downside, but budget for the possibility of forking and self-maintaining — treat that as a procurement question, not a footnote.
• It would collide with another bundle already replacing or decorating Doctrine metadata. Audit before committing, and benchmark the metadata factory on entity-heavy codebases.
• You can't add the CI guardrail. Without it, a developer deleting a field without the attribute is a silent, hard-to-diagnose incident — the exact failure the tool exists to prevent.

Risk notes for the decision record: disabled fields vanish from ORM introspection, so failures surface as wrong query results or missing-property exceptions rather than loud errors; setup is manual YAML, so config drift is real; and "re-enable" rollback means removing the attribute and redeploying — fine, but not instant.

How to Pitch It (Stakeholders)

For executives (one paragraph): "We run several versions of the app at once during deploys, which today means either a maintenance window or a risky all-at-once migration whenever we want to drop a database column. This is a small MIT-licensed Symfony add-on that lets a new version ignore a column while the old version keeps using it — so retiring a column becomes two ordinary deploys instead of one coordinated, downtime-inducing event. Think of it as a feature flag for our database schema. The cost is near zero, the code footprint is tiny, and it ships with a static-analysis rule and a CI check that block the one dangerous misuse — deleting a field without flagging it first. The caveats: it's a single-maintainer, zero-adoption open-source project, so I'd want to pilot on one service and accept that we may end up owning a fork; and it's Symfony-only, so it does nothing for our Laravel services."

For engineering (the ask): "Add dualmedia/disable-orm-bundle, register DualMedia\DisableORMBundle\DisableORMBundle in config/bundles.php, and set class_metadata_factory_name: DualMedia\DisableORMBundle\Factory on the entity manager. Keep the default disable_on_commands list so doctrine:schema:validate and doctrine:migrations:diff still see the field. The workflow is: ensure the column has a DB default, tag the property #[DisableORM], deploy, then drop the column in a follow-up migration. Add the extension.neon PHPStan include and the /scripts git change-detection job to CI so a field can't be deleted without having been flagged first. Pilot on one low-traffic entity, verify repository/query-builder/hydration behavior and any metadata-consuming bundle, then roll out. Keep a one-line runbook: 'Column missing or query returning fewer fields? Check whether the property is #[DisableORM]-tagged.'"

Sequencing for the delivery lead: pilot on non-critical entities → validate queries and admin/API layers → add the PHPStan and CI gates → then make it the standard path for column removals, with @deprecated annotations as the on-ramp.