Doctrine Fixtures Generator Bundle Laravel Package

Getting Started

This bundle adds a console command that reverse-engineers Doctrine data into fixture classes: point it at an entity and a set of IDs, and it writes a PHP DataFixtures class you can load with doctrine/doctrine-fixtures-bundle.

1. Install (with a compatibility check first). The last release is from 2019, so verify it resolves against your PHP/Symfony/Doctrine versions before committing to it:

composer require --dev webonaute/doctrine-fixtures-generator-bundle

If Composer refuses, check composer why-not webonaute/doctrine-fixtures-generator-bundle — the usual culprit is a PHP or doctrine/orm constraint that predates your stack.

2. Register the bundle. In config/bundles.php:

return [
    // ...
    Webonaute\DoctrineFixturesGeneratorBundle\WebonauteDoctrineFixturesGeneratorBundle::class => ['dev' => true, 'test' => true],
];

Keep it in dev/test only — it's a developer tool, not something that should be resolvable in prod.

3. Where to look first. Before running anything, inspect the actual surface area from the console, since READMEs from this era drift:

bin/console list doctrine:fixtures
bin/console doctrine:fixtures:generate --help

--help is authoritative for argument names and flags on the version you installed.

4. First use case. You have a hand-curated dev database (a few users, a few products, some orders) and want to turn it into a committed fixture set:

bin/console doctrine:fixtures:generate "App\Entity\Product" --ids=1,2,3 --dump-path=src/DataFixtures/

Then load it the normal way:

bin/console doctrine:fixtures:load --group=generated

The generated file is plain Doctrine fixtures PHP — you own it from the moment it's written.

Implementation Patterns

Generate from a curated dataset, not production. The intended workflow is: seed a local/staging DB with a small, meaningful slice of real data, then generate fixtures from that slice. Generating from a full production table produces multi-megabyte fixture files with thousands of addReference() calls that nobody will review.

Scope with IDs and where clauses. Rather than dumping whole tables, slice deliberately:

# Specific records
bin/console doctrine:fixtures:generate "App\Entity\Order" --ids=100,101,102

# A coherent family of records for one tenant
bin/console doctrine:fixtures:generate "App\Entity\Invoice" --where="o.customer = 42" --limit=20

Use --limit as a safety rail when you're exploring an unfamiliar entity.

Generate in dependency order, then wire references. Generated fixtures typically call $this->addReference('entity-<id>', $object) per record. That means order matters: generate parents (User, Category) before children (Order, Product), and load them in the same order. If a relation points at a row you didn't include, the generated fixture will hold a dangling reference or a persisted stub — fix these by hand or regenerate with the related IDs included.

One directory per fixture "group". Use --dump-path and the bundle's namespace option to separate datasets:

src/DataFixtures/
├── Core/        # users, roles, reference data — always loaded
├── Catalog/     # products, categories — loaded for catalog work
└── Scenario/    # the specific bug reproduction or demo

This makes doctrine:fixtures:load --group=Core (and Liip's --fixtures filtering in tests) practical.

Treat output as a first draft. The realistic loop is:

1. Generate.
2. Delete sensitive fields (emails, tokens, hashes) and replace them with faker/constants.
3. Strip hardcoded timestamps you don't care about.
4. Commit the cleaned file as a stable, reviewable fixture.

Once the file is committed, stop regenerating it — a fixture you hand-maintain is worth more than a fresh dump of whatever happens to be in your DB today.

Combine with Liip for functional tests. A Scenario group generated this way is ideal for reproducing a bug: dump the rows involved, commit the fixture, write a test that loads that group and asserts. The fixture becomes the regression test's fixed setup.

Multiple entity managers. Pass the entity manager name to the generator if you have more than one configured; otherwise it targets the default and your fixture will persist into the wrong connection.

Gotchas and Tips

Maintenance risk is the headline. Last release 2019-06-25, zero dependents. Budget for the possibility that it simply won't install on Symfony 6/7 or PHP 8.2+. If it doesn't, the fallback is a few lines of custom code: run a DQL query for your IDs, loop the entities, and emit addReference()/persist() — this bundle saves you maybe an hour, so don't sink a day into making it resolve.

Hardcoded IDs collide with sequences. Generated fixtures often set explicit IDs. On PostgreSQL, inserts that specify id do not advance the sequence, so the first subsequent $em->flush() in your app will throw a unique-constraint violation. Either let the ORM assign IDs, or reset the sequence after loading (ALTER SEQUENCE ... RESTART WITH ...).

Generated code is a snapshot, not a model. It bakes in the exact column values of that moment. Any schema change to the entity — renamed property, dropped field, new non-nullable column — leaves the fixture silently stale. Add fixture loading to CI so breakage surfaces immediately rather than the next time someone happens to run it.

Relations are the weak point. Owning-side collections, many-to-many join tables, and cascaded operations are where generated output most often needs manual repair. After generating, always load the fixture into an empty schema and immediately assert the object graph in php -r or a throwaway test — don't discover dangling references mid-presentation.

Blobs and large text will wreck your diff. BLOB/JSON columns get inlined into the generated file. Null them out before committing, or your fixture becomes unreadable and unreviewable.

Secrets leak into source control. Password hashes, API tokens, and real customer emails come straight out of the source database into a PHP file that gets committed. Grep the generated output for password, token, secret, email before the first commit — this is the single most likely way this tool causes an incident.

Config quirks. Fixture namespace and default dump path are bundle configuration. If generated classes land in the wrong namespace, they'll autoload-fail without an obvious error — check config/packages/ for the bundle's config block and confirm it matches your composer.json PSR-4 mapping.

Debugging failed generation. If the command silently produces nothing, the ID set probably doesn't exist under that entity manager or the entity name isn't resolvable (try the FQCN instead of the short AppBundle:Entity alias). Run with -vvv to see the underlying DQL.

Extension points are thin. Expect to override by post-processing the generated file (a small PHP-CS-Fixer rule, or a sed pass in your Makefile) rather than via bundle hooks. Keeping the post-processing scripted makes regeneration reproducible; doing it by hand makes the whole workflow fragile.