Weave Code
Doctrine2 Exporter Laravel Package
mysql-workbench-schema-exporter/doctrine2-exporter
Plugin for MySQL Workbench Schema Exporter that converts .mwb models into Doctrine 2 entity classes. Generate PHP entities, mappings, and relations directly from your MySQL Workbench diagrams, keeping your database schema and code in sync.
MySQL Workbench Exporter for Doctrine 2
Frequently asked questions about Doctrine2 Exporter
- What does mysql-workbench-schema-exporter/doctrine2-exporter actually do?
- It is a plugin for MySQL Workbench Schema Exporter that reads .mwb model files and generates Doctrine 2 entity classes, including mappings and relations. It is a development-time scaffolding tool rather than a runtime library, so nothing ships to production. Laravel teams typically use it to bootstrap a starting domain model from an existing database diagram. The repository is unknown and ecosystem validation is low, so validate output quality on a real schema before relying on it.
- How do I install the Doctrine 2 exporter with Composer?
- Install it as a dev dependency alongside the base mysql-workbench-schema-exporter package, then invoke the exporter from the command line against your .mwb file. Keep it in require-dev or a separate tooling repository so it never becomes a production runtime dependency. Pin the version in composer.json and commit the generated entities to version control so upgrades are deliberate.
- Is this package compatible with Laravel applications?
- It is adjacent rather than native to Laravel because it generates Doctrine 2 entities, not Eloquent models. It fits Laravel codebases that already use Doctrine for part of the domain, or migration work where MySQL Workbench is the source of truth. For Eloquent-only apps, use the output as reference scaffolding and translate it into Eloquent models, migrations, factories, and policies. Avoid introducing Doctrine solely to satisfy the exporter.
- Does it generate Doctrine attributes or only legacy annotations?
- This is a key validation question and cannot be assumed from the package metadata, since it may emit legacy Doctrine annotations rather than PHP attributes. Check the generated output against your Doctrine ORM version before committing, because annotations are deprecated in Doctrine ORM 2.x and removed in 3.x. If you need attributes, budget for customizing the templates or adding a post-processing step to the generation workflow.
- How does it map relations, composite keys, indexes, and enums?
- The exporter is designed to translate Workbench diagrams into entity classes with mappings and relations, but fidelity for composite keys, indexes, enums, custom column types, and nullability must be verified per schema. Run a pilot on one non-critical schema and compare the generated entities against expected domain behavior. Expect manual adaptation of naming, relationship inverses, and custom column types before the output is usable.
- Can I customize the generated entity output without patching the package?
- Customization typically happens through the exporter's templating layer rather than by editing the package itself, but confirm which templates and hooks are actually exposed. If the extension points are too narrow, keep a thin post-generation script that rewrites namespaces, adds attributes, or fixes column types. Avoid patching vendor code directly unless you are prepared to fork and maintain it long term.
- Is this package actively maintained and compatible with current PHP and Doctrine versions?
- Treat maintenance as uncertain: the repository is unknown and ecosystem validation is low, which raises abandonment risk. Verify PHP and Doctrine ORM constraints in composer.json and test against your actual toolchain before adopting. Plan for an internal owner and a fork-or-vendor fallback strategy. Pin versions so that upgrades of the generator are always deliberate decisions.
- Should it be a require-dev dependency or a production dependency?
- Use require-dev or a dedicated tooling repository. The package is a schema-generation utility, not a Laravel runtime component, so it should never be loaded in production. Keeping it out of production also limits supply-chain and upgrade risk. The generated entities are what you own and deploy, not the generator itself.
- How should I test generated Doctrine entities before adopting the exporter?
- Run a time-boxed spike: generate entities into an isolated namespace and diff the output against an expected model. Test relations, composite keys, enums, nullability, and naming against a real but non-critical schema. Define a review checklist for generated code and a regeneration policy before wiring anything into CI. Only adopt it as a repeatable pipeline if the spike proves consistent across schemas.
- What are the alternatives if the exporter is abandoned or output quality is poor?
- Fall back to manual Eloquent modeling, a custom .mwb parser, or generating migrations directly from the Workbench model. If you already use Doctrine, check for maintained alternatives or keep a vendored fork with your own patches. Decide based on long-term ownership cost rather than initial generation speed. The generated code must be reviewed and owned by the application team regardless of the tool used.
Weaver
How can I help you explore Laravel packages today?