Disable Orm Bundle Laravel Package

Product Decisions This Supports

• Zero-Downtime Schema Migrations: Enables safe removal of database fields without requiring coordinated downtime across all application instances, critical for high-availability systems or continuous deployment pipelines.
• Backward Compatibility in Multi-Version Deployments: Supports canary releases, blue-green deployments, or A/B testing where old and new application versions must coexist with the same database schema.
• Risk Mitigation for Schema Changes: Reduces the risk of schema migration failures (e.g., ALTER TABLE conflicts, lock contention) by decoupling field removal from database migrations.
• Legacy System Modernization: Facilitates gradual modernization of legacy systems by allowing teams to deprecate fields in code before removing them from the database, reducing technical debt incrementally.
• Build vs. Buy Decision: Avoids reinventing a custom schema migration solution, leveraging a lightweight, MIT-licensed package with minimal maintenance overhead.
• Use Cases:
  • Phased Feature Rollouts: Remove database fields for deprecated features while keeping old versions functional.
  • Database Refactoring: Safely restructure schemas (e.g., splitting tables, renaming columns) without blocking deployments.
  • Compliance/Regulatory Changes: Remove PII or sensitive fields from production systems while maintaining audit trails in legacy versions.
  • Performance Optimizations: Drop unused columns to reduce query overhead or storage costs.

When to Consider This Package

• Adopt When:
  • Your application deploys multiple versions simultaneously (e.g., canary, blue-green, or rolling updates) and requires database schema changes without downtime.
  • You need to remove database fields but cannot coordinate a full migration (e.g., due to lock contention, third-party dependencies, or global deployments).
  • Your team uses Symfony + Doctrine ORM and wants a minimal, non-intrusive solution for schema evolution.
  • You have legacy code that relies on raw SQL or dynamic property access, and you need to preserve backward compatibility while modernizing.
  • You’re phasing out features and want to deprecate fields in code before removing them from the database (e.g., for analytics or audit purposes).
• Look Elsewhere If:
  • Your deployments are version-locked (no parallel operation of old/new app versions).
  • You require strict ORM consistency across all versions (e.g., no raw SQL fallbacks).
  • The package’s lack of adoption (0 stars, 0 dependents) raises concerns about long-term maintenance (mitigate via internal testing or forking).
  • You need dynamic toggling of fields (e.g., feature flags for database fields) rather than a one-way disable.
  • Your team lacks experience with Doctrine metadata customization, as misconfiguration could lead to silent failures or data corruption.
  • You’re using Doctrine extensions (e.g., Gedmo, Stof) that might conflict with the metadata factory override.

How to Pitch It (Stakeholders)

For Executives: "This bundle lets us remove database fields from newer app versions without downtime or migration risks, enabling safer, faster deployments. Imagine updating a global system where old versions must keep running—this tool lets us deprecate fields in code first, then safely remove them from the database later. It’s like a schema migration on autopilot, reducing the risk of failed deployments and cutting downtime costs. For example, if we’re retiring an old feature, we can disable its database fields in the new version while keeping legacy systems running until they’re fully phased out."

For Engineering: *"The DisableORMBundle solves a critical pain point in multi-version Symfony/Doctrine deployments: removing database fields without downtime. Here’s how it works:

1. Mark a field for exclusion with @DisableORM in your entity.
2. Deploy the new version—Doctrine ignores the field, but raw SQL still accesses it.
3. Remove the field from the database in a later migration (no rush, no locks).
4. Profit: No schema conflicts, no downtime, and no blocking old versions.

Key Benefits:

• Zero-downtime schema changes: No more coordinating migrations across all instances.
• Backward compatibility: Legacy systems can still query excluded fields via raw SQL.
• Minimal setup: Just add the bundle, configure the metadata factory, and annotate fields.
• Safe deprecation: Deprecate fields in code before removing them from the DB.

Caveats:

• Permanent exclusion: Fields are gone from the ORM layer forever (no re-enabling).
• Raw SQL required: Legacy code must use QueryBuilder or executeQuery() for excluded fields.
• Testing needed: Validate queries, hydration, and third-party integrations post-integration.

Use Case Example: If we’re sunsetting a legacy payment processor, we can:

1. Add @DisableORM to its fields in the new version.
2. Deploy the new version while old versions keep processing payments.
3. Remove the fields from the DB in a low-risk migration later.

Next Steps:

1. Pilot with a non-critical entity (e.g., audit logs).
2. Test raw SQL queries and legacy code paths.
3. Automate CI checks to catch @DisableORM misuse.
4. Document the process for future schema changes."*

For Data/Infrastructure Teams: *"This bundle decouples schema evolution from deployment cycles, reducing the risk of migration failures. For example:

• No more blocked deployments due to schema locks.
• No more rushed migrations to avoid downtime.
• Cleaner databases by removing unused fields incrementally.

Trade-off: Excluded fields are only accessible via raw SQL, so we’ll need to update legacy queries or document the limitation for teams using dynamic property access."*