Doctrine Schema Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin Symfony Bundle whose entire public surface is three interfaces: SchemaImporterInterface (YAML string/file → Doctrine\DBAL\Schema), SchemaExporterInterface (Doctrine\DBAL\Schema → YAML), and SchemaBuilderInterface (event-driven aggregation of multiple YAML sources into one schema). This is an unopinionated seam, not a framework — it does not own migrations, connection management, or DDL execution.
• Fit is strong only for Symfony applications that are already Doctrine/DBAL-centric and want declarative, DBMS-agnostic schema definitions as source of truth. It composes naturally with Symfony's DI (autowired services) and EventDispatcher (priority-ordered subscribers), which is idiomatic and low-friction for existing bundle-based codebases.
• The extensibility model is the real architectural value: multiple modules/bundles can each ship a YAML fragment and contribute to a single assembled schema via SchemaBuilderEvents::BUILD_SCHEMA, which maps cleanly onto modular monolith or plugin architectures where schema ownership should be distributed.
• Architectural mismatch risk: it is not a migration tool. There is no diffing, versioning, or apply step described. Teams expecting "Doctrine Migrations but YAML" will mis-scope this. It produces schema objects; something else must persist them.

Integration feasibility

• Mechanically trivial: Composer install, bundle registration, YAML authoring, optional EventSubscriber. The README's two code samples are sufficient to get a working proof of concept in under a day for a Doctrine-fluent engineer.
• Hard constraints are explicit: PHP 8.3+ (raised in 5.0.0-beta1) and Symfony 6/7 (Symfony 7.4 LTS per IBX-11247). Symfony 5.x or PHP 8.1/8.2 estates are locked to the 4.6 line.
• Two release lines must be tracked: 4.6.x (LTS-style, still receiving backports such as IBX-12043 DatabasePlatformResolver) and 5.0.x (current). Choosing wrong means either a dead end or an unsupported PHP/Symfony baseline.
• The custom YAML DSL is the actual integration cost — and it is undocumented here. No schema reference, no type mapping table, no vendor-specific behavior notes are present in the provided materials. Expect reverse-engineering from source or from Ibexa DXP's own shipped YAML. Budget this as the dominant effort, not the bundle wiring.

Technical risk

• License is the primary blocker. NOASSERTION is accurate: the package is dual-licensed under the Ibexa Business Use License (requires a paid Ibexa DXP subscription) or GPL-2.0. GPL-2.0 is copyleft and, for a PHP library linked into an application, is widely treated as infectious. Most commercial products cannot adopt this without either a subscription or a legal opinion. This single item can invalidate the entire evaluation.
• Zero dependents and 4 stars indicate no external validation. This is an internal Ibexa platform component published for their own dependency graph, not a community-maintained library. No third-party production usage to learn from, no Stack Overflow corpus, no issue-driven edge-case documentation.
• Vendor bus factor. Roadmap, PHP/Symfony baselines, and DBAL compatibility are decided by Ibexa's DXP release train. The 4.6.32 DatabasePlatformResolver addition signals that DBAL version drift has already caused breakage — cross-DBAL-version platform detection is a symptom of a moving dependency.
• Format lock-in. The YAML dialect is proprietary to this bundle. Every table, index, and foreign key expressed in it is a migration liability if the package is abandoned. Mitigation is cheap (the exporter can round-trip back to a Schema object), but only if planned for up front.
• Cross-DBMS claims are unverified here. "Cross-DBMS schema import" is asserted; the material shows no test matrix across MySQL/PostgreSQL/MariaDB/SQLite, and type/index/sequence semantics differ materially. Treat as a hypothesis to be tested, not a feature.
• Release notes are overwhelmingly "No significant changes," which reads as low churn (good for stability) but equally as low investment (bad for issue response).

Key questions

1. Can Legal accept GPL-2.0 copyleft, or is an Ibexa DXP subscription in scope? If neither — stop here.
2. Does our actual problem require DBMS portability, or is the "custom YAML for schema" the real want? A hand-rolled YAML→Schema mapping or doctrine/doctrine-migrations may cover 80% at zero license risk.
3. Who owns the YAML dialect documentation if we adopt it — do we fund reverse-engineering and internal docs, or block on upstream?
4. Which DBMS/DBAL version pairs must we support, and has anyone verified the type mapping on each?
5. Is the 4.6 or 5.0 line our target, and what is our PHP/Symfony baseline today and in 12 months?
6. What is the exit plan if Ibexa drops the package — do we require exporter round-tripping as an acceptance criterion?

Integration Approach

Stack fit

• Target: PHP 8.3+, Symfony 6.4/7.x, Doctrine DBAL already present as a transitive dependency. This bundle slots in beside doctrine/doctrine-bundle rather than replacing it — it feeds Schema objects into whatever already consumes them.
• Best-fit use cases, in descending order of value:
  1. Existing Ibexa DXP deployments — adoption is effectively free and unavoidable.
  2. Symfony products shipping to multiple DBMS vendors where one declarative schema must generate platform-specific DDL.
  3. Modular monoliths where independent modules must contribute schema fragments without a shared migration file.
• Poor fit: single-database CRUD apps (native migrations are simpler), teams without Doctrine fluency, or anywhere the GPL question is unresolved.

Migration path

• Greenfield: author YAML as source of truth, use SchemaBuilder + subscribers per module, generate DDL from the resulting Schema object. Lowest cost, cleanest ownership.
• Brownfield, incremental: do not convert everything. Pick one bounded module, express it in YAML, and assert equivalence against the existing schema — use SchemaExporterInterface on the live/introspected Schema and diff against the handwritten YAML. This is the single highest-value use of the exporter: it turns an opaque format into a verifiable one and gives a free conformance test.
• Reverse-engineer first, commit second: run the exporter against a representative production schema to learn the DSL from real output rather than from absent docs. This collapses the documentation gap into a one-off spike.
• Reject-the-migration path must stay open: keep the exporter in CI so the YAML can be converted back to a Schema/SQL dump if the package is dropped. Make this a hard exit criterion.

Compatibility

• Pin the release line explicitly (^4.6 vs ^5.0) and pin DBAL. The DatabasePlatformResolver work in 4.6.32 exists because DBAL's platform-detection APIs moved; assume this is a recurring seam and let Composer enforce it.
• Verify per-target-DBMS behavior for the constructs that actually diverge: auto-increment/sequences, boolean, JSON, blob/text, enum, index prefix lengths, FK cascade, case sensitivity of identifiers, and column-collation options. Build a small YAML fixture that exercises each and run it against every DBMS in CI.
• Event-subscriber ordering is a correctness concern, not a style one: subscriber priority determines assembly order, and later subscribers can override earlier definitions. Establish an explicit priority convention (e.g., 200/100/0 bands) and document it internally before more than two modules contribute schema.
• Symfony 6 vs 7 compatibility should be validated by running the same fixtures on both if the estate is mixed; the 7.4 bump came in a patch release, which suggests the supported range is broad but not uniformly exercised.

Sequencing

1. Week 0 — license gate. Legal decision on GPL-2.0 vs BUL. Everything downstream is contingent.
2. Week 1 — spike. Throwaway Symfony 7 app: register bundle, import a 5-table YAML, export it, diff. Confirms the DSL is learnable and the round-trip is lossless.
3. Week 2 — cross-DBMS fixture matrix. Same YAML against each supported DBMS. This is where go/no-go on the portability premise is decided.
4. Week 3 — internal DSL reference. Document the format from exporter output and source. This artifact is what makes the package supportable by your team rather than by Ibexa.
5. Weeks 4–6 — one module in production. Bounded blast radius, exporter round-trip wired into CI, no other modules converted.
6. Post-adoption — decide on broader rollout only if the fixture matrix is green and no DSL gaps forced workarounds.

Operational Impact

Maintenance

• Low code churn, and most patch releases are literally "No significant changes." For an operator this is favorable: few upgrade-forced changes, long-lived pins, minimal regression surface.
• But low churn here correlates with low investment, not maturity. Do not expect the YAML format to grow features on your timeline; feature requests route through Ibexa's DXP backlog. Plan to own any DSL extension via the exporter/importer seams or accept workarounds.
• Dual-line maintenance is a real annual cost: security and Symfony/PHP baseline moves will likely land on 5.0 first, forcing a 4.6→5.0 migration on Ibexa's schedule (the 5.0 line already dropped class_alias BC layers and raised PHP to 8.3 — a breaking step teams must absorb).
• Because it is a build-time/schema-time library, dependency updates are the main ongoing task, and Composer handles most of it. Assign a named owner anyway; orphaned schema tooling is how YAML drifts from reality.

Support

• Commercial support requires an Ibexa DXP subscription under the BUL. Without one, you are on GPL-2.0 with community-only channels and a repository that shows minimal external activity (4 stars, 0 dependents). Assume no external expert pool.
• Internal supportability hinges entirely on the DSL documentation you produce in the sequencing step. Without it, every new engineer reads source. With it, this is a half-day onboarding topic.
• Escalation paths must be contractual, not aspirational: identify the Ibexa support channel and SLA before production, or accept that a blocking bug is worked around, not fixed.

Scaling

• Runtime cost is effectively zero — schema import/export is a build/deploy-time concern, not a request-path one. No throughput or latency implications.
• Deployment scaling is where cost appears: SchemaBuilder assembles the full schema from all registered subscribers on each build. With many modules and large schemas, build time grows with contributor count. Cache the built schema artifact per release rather than rebuilding per deploy target.
• Team scaling is the sharper constraint: every contributor must learn the YAML DSL and the event ordering convention. Beyond ~3–4 contributing modules, undocumented priority interactions become the dominant defect source. Codify conventions early.
• Multi-tenant or multi-DBMS deployments benefit most — one schema definition, N platform-specific DDL outputs — which is precisely the capability being purchased.

Failure modes

• License failure — adoption blocked or legally exposed post-hoc. Highest severity, zero technical signal. Only mitigation is pre-adoption legal review.
• Silent schema divergence — YAML and the live database drift because nothing diffs them. Mitigation: exporter round-trip diff in CI on every schema change.
• YAML parse/validation errors surface at deploy — a malformed fragment fails the build or, worse, produces a partial schema if a subscriber throws after others have imported. Mitigation: validate all YAML in CI, and treat buildSchema() as atomic/fail-fast — assert full expected table count.
• Subscriber ordering regression — a new subscriber with an unexpected priority silently overrides another module's table. Mitigation: fixed priority bands, a test asserting final schema shape, and code review on priority values.
• DBAL/platform drift — DatabasePlatformResolver exists because this already happened. Pin DBAL, run the DBMS fixture matrix on upgrades, and treat any DBAL major as a scheduled project.
• Upstream abandonment — low-probability given Ibexa's own dependency, but non-zero for a 0-dependent package. Mitigation: exporter round-trip and a documented fallback to raw SQL/Doctrine migrations.
• DBMS-specific construct gaps — a type or index option expressible in a target DBMS has no YAML representation, forcing raw SQL escape hatches that break portability. Mitigation: discover these in the week-2 fixture matrix, not in production.

Ramp-up

• For a Doctrine-fluent Symfony engineer: half a day to a working import, 2–3 days to confident authoring once an internal DSL reference exists. Without that reference: 1–2 weeks of source reading — the documentation gap, not the API, is the onboarding cost.
• The three interfaces and one event are the entire conceptual model; there is no framework to learn. This is the package's genuine strength and the reason a spike is cheap.
• Organizational ramp-up is the slower half: legal review, release-line decision, priority conventions, and the CI fixture matrix. Budget 4–6 weeks end-to-end for a first production module, of which engineering is roughly one.
• Net TPM position: technically low-risk and cheap to trial, strategically gated on license and on the unproven cross-DBMS premise. Run the license gate and the two-week spike in parallel; approve broader adoption only if both clear and the exporter round-trip is enforced in CI from day one.