Doctrine2 Exporter Laravel Package

Getting Started

This is an exporter plugin, not a standalone tool. It plugs into the mysql-workbench-schema-exporter core package and turns a MySQL Workbench .mwb model into Doctrine 2 entity classes.

Minimal setup:

composer require --dev \
  mysql-workbench-schema-exporter/mysql-workbench-schema-exporter \
  mysql-workbench-schema-exporter/doctrine2-exporter

Verify registration and discover options:

vendor/bin/mysql-workbench-schema-exporter list
vendor/bin/mysql-workbench-schema-exporter export --help

First export (dump generated code somewhere safe before wiring it into src/):

mkdir -p build/entities
vendor/bin/mysql-workbench-schema-exporter export database/schema.mwb \
  --exporter=doctrine2 \
  --output=build/entities

Then inspect build/entities/*.php. Once the output looks right, add a small config file (committed) so the flags are not re-typed each run — the exporter reads options from JSON/YAML so you can pin the base namespace, output directory, annotation style, and constructor/getter/setter generation.

Where to look first, in order:

1. build/entities/ — confirm class names, namespaces, and FK associations match your intent.
2. The package's bundled templates (under vendor/mysql-workbench-schema-exporter/doctrine2-exporter/.../Templates) — read these before customizing anything.
3. Your .mwb model — the exporter is only as good as the model's naming and relations.

First real use case: you've designed a schema in Workbench and want Doctrine entities plus associations without hand-writing a dozen classes. Generate into a scratch directory, review, then move the files that are correct.

Implementation Patterns

Config-file driven runs. Put the options in doctrine2.json (or YAML) at the repo root or under database/ so CI and local runs behave identically. Keep the .mwb model in the repo alongside it — the model is the source of truth, not the generated PHP.

Generate-then-diff workflow. Never run the exporter directly against src/Entity. Always export to a temp directory and diff:

rm -rf build/entities && \
  vendor/bin/mysql-workbench-schema-exporter export database/schema.mwb \
    --exporter=doctrine2 --config=database/doctrine2.json --output=build/entities
git diff --no-index --stat src/Entity build/entities || true

Copy only the files you actually want. This keeps hand-written business methods (validators, domain helpers, to-string logic) from being clobbered.

Treat it as a scaffolder, not a codegen lock-in. The typical lifecycle: designer updates .mwb → export → diff → manually merge new columns/relations into existing entities → write a Doctrine migration. Do not attempt to round-trip generated entities back into the model.

Multi-namespace / multi-bundle projects. Override the base namespace in config to target the right App\Entity or module namespace, and use per-table overrides where the exporter supports them so join tables or audit tables land in a different place (or are skipped entirely).

Custom templates for house style. Copy the bundled templates into resources/mysql-workbench-schema-exporter/templates/ (or similar), point config at them, and edit. This is the supported extension point: add @ORM\HasLifecycleCallbacks, a base class extends, a custom trait, or change the docblock format without touching vendor code.

CI guard-rail. Add a job that runs the export against the committed model and fails if the schema has drifted from committed entities. That catches "forgot to update entities after a model change" without generating files on the fly.

Docker for PHP version parity. Pin a PHP version matching the runtime in a container. This exporter predates PHP 8 attributes, so you are usually generating Doctrine annotations — run it where the target Doctrine version lives.

Gotchas and Tips

• The .mwb file is the real input. Commit it, and treat the generated code as disposable scaffolding. A .mwb that isn't versioned makes the exporter useless across machines.
• File overwrites are silent. Default behavior writes into the output directory. Use a temp dir plus git diff (pattern above) rather than pointing it at src/Entity. If the tool offers a backup flag, still don't rely on it — diffs are clearer.
• Type mapping gaps. ENUM, SET, JSON, spatial types, and unsigned integers frequently map to something lossy or unexpected. Grep the generated entities for the columns you care about, not just the FK relations.
• Association inference depends on real FKs. Relationships defined only in Workbench's "foreign keys" UI without corresponding columns will not produce associations. Verify @ORM\ManyToOne etc. exist where you expect.
• Reserved words and odd column names. A column like order or class can produce a property name that collides with PHP keywords or Doctrine internals. Sanitize in the model or in a custom template.
• Annotation vs. attribute era. This plugin targets Doctrine 2 annotations. If your project is on PHP 8+ with attributes or Doctrine 3, plan on either running an annotation-to-attribute conversion pass or heavily customizing templates.
• Template path resolution is fiddly. Relative template paths resolve against the tool's working directory, not the config file. Use absolute paths in CI configs.
• No idempotency guarantee on reruns if the model changes types — a varchar(255) → text change may flip the generated property's nullable/type annotations. Always diff, never blind-copy.
• Don't put logic in generated entities. Keep generated files as thin property/getter/setter shells; extend them or use traits for anything hand-authored, so regeneration is a merge rather than a rewrite.
• Extension points: custom templates (primary), config overrides per table, and — for anything templates can't express — post-processing the generated output with a small script (Rector/PHP-CS-Fixer rules) is often cleaner than fighting the template engine.
• Debugging odd output: run the export on a single-table test model first. Isolating to one table quickly tells you whether the problem is the model, the type mapping, or the template.