Materialized View Bundle Laravel Package

Product Decisions This Supports

• Deploy reliability and operational toil: v1.3.1 fixes a boot-time abort in matview:doctrine-lane when the Doctrine migration metadata table (doctrine_migration_versions) has drifted. The lane now self-heals the metadata storage before reading migration status, under the advisory lock, for every strategy. This directly reduces on-call pages and manual doctrine:migrations:migrate interventions during deploys.
• Build vs. buy for migration orchestration: The package now provides behavior parity with plain doctrine:migrations:migrate for metadata-storage drift, plus advisory-lock safety. Teams evaluating custom deploy scripts should weigh this against building their own guarded migration lane.
• Adoption risk for zero-downtime deploy pipelines: The fix is idempotent and a no-op once the metadata storage is current, so it lowers the risk of adopting the package in existing deploy pipelines that already run Doctrine migrations alongside materialized views.
• Roadmap input for platform/deploy tooling: If the team maintains Laravel services with Doctrine migrations, this release removes a known class of deploy failure and may justify standardizing on the package rather than per-service workarounds.
• Use cases supported: Postgres/MySQL deployments using advisory locks, materialized views managed alongside Doctrine migrations, and environments where migration metadata can drift due to manual changes, restore operations, or schema management outside the normal migration path.

When to Consider This Package

Consider adoption when:

• The application is a Laravel service using doctrine/migrations rather than, or in addition to, Laravel’s native migrations.
• The deploy process must be safe under concurrency, and the underlying database supports advisory locks (e.g., PostgreSQL, MySQL).
• Materialized views are part of the schema and must be coordinated with Doctrine migrations.
• The team has experienced metadata-storage drift or deploy aborts caused by "The metadata storage is not up to date…" and wants self-healing behavior under lock.
• You want a narrow, single-purpose lane command rather than a full deployment orchestrator.

Look elsewhere when:

• The application only uses Laravel’s native migration system and has no Doctrine migrations or materialized-view lifecycle needs.
• The database does not support advisory locks in the way the package expects.
• The team needs a complete deployment platform with rollback orchestration, canary analysis, or multi-service coordination.
• The team cannot accept package-level responsibility for mutating Doctrine’s metadata storage, even idempotently, during boot or deploy.

How to Pitch It (Stakeholders)

For executives: This is a low-risk patch release that removes a class of deploy failures. Previously, a drifted migration metadata table could abort the deploy lane before any migration ran, requiring manual intervention. The package now self-heals that drift automatically under the same advisory lock used for migrations — matching the behavior teams already expect from plain Doctrine migrations. There are no breaking changes in this release.

For engineering: v1.3.1 initializes Doctrine’s metadata storage on the guard’s DependencyFactory before the first hasPendingMigrations() status read, for every migration strategy, under the advisory lock. The operation is idempotent and a no-op once the metadata storage is current. This closes the gap where DoctrineLane read migration status before ensureInitialized() was called, causing a boot abort on drifted doctrine_migration_versions schemas. Review PR #4 for implementation details. Recommend validating in staging with a deliberately drifted metadata table before rollout.