Weave Code
Doctrine Schema Laravel Package
ibexa/doctrine-schema
A Symfony bundle providing a cross-DBMS schema import abstraction layer. It defines a custom YAML schema format and autowired APIs, plus an event-driven SchemaBuilder and interfaces for importing and exporting Doctrine DBAL schema objects.
ibexa/doctrine-schema is a Symfony bundle that provides a basic abstraction layer for cross-DBMS schema import. It introduces a custom YAML format for defining schemas, making it easy to import and export database structures independently of the underlying database system.
The bundle exposes autowired APIs through the SchemaImporterInterface, SchemaExporterInterface, and SchemaBuilderInterface contracts. The SchemaBuilder is event-driven, letting projects hook into schema construction with custom event subscribers.
- Import YAML strings or files into
Doctrine\DBAL\Schemaobjects - Export Doctrine schema objects back to YAML
- Extensible, event-driven schema building via subscribers
- Cross-DBMS compatible schema definitions
Frequently asked questions about Doctrine Schema
- What does ibexa/doctrine-schema actually do?
- It is a Symfony bundle that adds a custom YAML schema definition format on top of Doctrine DBAL Schema. It exposes three contracts: SchemaImporterInterface (YAML string or file into a Doctrine\DBAL\Schema object), SchemaExporterInterface (the reverse), and SchemaBuilderInterface. The SchemaBuilder is event-driven, letting bundles register subscribers on SchemaBuilderEvents::BUILD_SCHEMA and contribute schema fragments that are merged into one coherent Schema. Its real value is composing a single schema for a modular monolith where many bundles each own their own tables.
- Can I use ibexa/doctrine-schema in a Laravel application?
- No, not practically. This is a Symfony bundle: there is no Laravel service provider, no Artisan commands, and no Eloquent bridge, and the wiring relies entirely on Symfony's kernel and dependency injection container. You could theoretically consume the contracts standalone, but you would have to reimplement the bundle's container configuration yourself, at which point you are maintaining a fork rather than adopting a package. If your application is Laravel, this is a hard no.
- How do I install and configure ibexa/doctrine-schema?
- Install with Composer and register the bundle in your Symfony kernel or bundles.php, then autowire SchemaImporterInterface, SchemaExporterInterface, or SchemaBuilderInterface where needed. To contribute schema fragments you create an EventSubscriber that subscribes to SchemaBuilderEvents::BUILD_SCHEMA with a priority and calls importSchemaFromFile or importSchemaFromString on the event's schema builder. After that you call buildSchema() to get a merged Doctrine\DBAL\Schema object. Inside Symfony the mechanics are simple; the friction is in the undocumented YAML grammar and merge semantics.
- Which PHP and Symfony versions does ibexa/doctrine-schema support?
- The 5.x line requires PHP 8.3 or newer plus Symfony 6.4 or 7.x, and release 5.0.7 bumped Symfony dependencies to the 7.4 LTS. The 5.0 release was a hard break: it dropped class_alias backward-compatibility shims and raised the PHP floor. Assume future Symfony majors will require corresponding major bumps here, so pin to a specific minor and track the 5.0 line if you need Symfony 7.4 LTS.
- What license is ibexa/doctrine-schema under and can I ship it in a commercial product?
- It is dual-licensed: the Ibexa Business Use License v2.4 or later, which is granted only with an active Ibexa DXP subscription, or GPL-2.0. GPL-2.0 copyleft is incompatible with distributing proprietary closed-source software, and the BUL is unavailable unless you are an Ibexa DXP customer. The NOASSERTION license field on the repository is a symptom of this dual arrangement, not noise. If neither option fits your codebase, stop evaluating here.
- Where is the YAML schema format documented?
- The README shows the extension mechanism but never specifies the YAML grammar itself. Column types, index and constraint syntax, foreign key definitions, platform-specific options, and merge semantics are only discoverable by reading the source and the test suite. There is no documented statement that the YAML format is a versioned public contract with a backward-compatibility promise, so treat it as an internal implementation detail that could shift between releases. Budget time to reverse-engineer the format before committing.
- How does the event-driven SchemaBuilder merge schemas from multiple bundles?
- Each bundle registers an EventSubscriber on SchemaBuilderEvents::BUILD_SCHEMA with a priority, and each subscriber imports its own YAML fragment into the shared builder. The builder then merges all contributed fragments into a single Doctrine\DBAL\Schema object returned by buildSchema(). What happens when two subscribers define the same table, or when priorities conflict, is not documented and must be verified from source or tests. This is a meaningful unknown for a modular monolith where table ownership can overlap.
- Can SchemaExporterInterface round-trip an existing production schema without data loss?
- That is unproven and should be the first thing you test. The cross-DBMS claim is aspirational and is likely to leak on platform-specific constructs such as JSON columns, enums, generated columns, and collations. A sound gate is to export your live schema to YAML, import it back, and diff the resulting Doctrine\DBAL\Schema object against the actual database; only a clean, empty diff justifies proceeding. If the export is lossy you will learn that in days rather than quarters.
- Is ibexa/doctrine-schema actively maintained and what is the bus factor?
- It has roughly four GitHub stars and no meaningful external dependents, so there is no community validation, no third-party answers to problems, and effectively a single-vendor bus factor. Maintenance commitment to the 4.6.x versus 5.0.x lines, and the support window for each, is not publicly clear. Before adopting, identify internally who would own a fork if Ibexa deprioritizes the package.
- What are the alternatives if I need cross-DBMS schema import and export?
- For Laravel applications the natural answer is Laravel's own migrations combined with the schema builder, plus doctrine/dbal when you need schema introspection and column comparison. Symfony projects can use doctrine/doctrine-bundle and doctrine/migrations directly, or rely on Doctrine's own schema tooling for diffing. If you need a portable, human-authored schema file, evaluate those options first; adopting a bespoke YAML dialect just to reach Doctrine functionality you already have is rarely justified.
Weaver
How can I help you explore Laravel packages today?