Doctrine Fixes Bundle Laravel Package

Getting Started

Install and register the bundle in a Symfony project (it is a Symfony bundle, so 3.x/4.x/5.x conventions apply — check composer.json inside the package for the supported Symfony/Doctrine range before running the command):

composer require omasn/doctrine-fixes-bundle

Register it in config/bundles.php (or app/AppKernel.php on legacy Symfony). It has no routes, no UI, and generally no required config — the entire value of the package is delivered through service decoration/compiler passes, so config/packages/*.yaml is usually empty.

Where to look first, in this order:

1. vendor/omasn/doctrine-fixes-bundle/src/ — read the bundle class, then the DependencyInjection/ directory. Anything named *CompilerPass, *Decorator, or a services.xml that rebinds a doctrine.* service tells you exactly what is being patched.
2. vendor/omasn/doctrine-fixes-bundle/composer.json — this is the real compatibility contract. Note the doctrine/orm, doctrine/dbal, and symfony/framework-bundle constraints; the bundle is only meaningful on the DBAL/ORM versions it was written against.
3. The README.md — at two stars it may be the only documentation, and it will list which Doctrine bugs are targeted.

First use case: treat the bundle as a diff generator. In a scratch branch, run these commands without the bundle, commit the output, then enable the bundle, clear the cache, and run them again:

php bin/console doctrine:schema:validate
php bin/console doctrine:schema:update --dump-sql
php bin/console doctrine:migrations:diff

The delta between the two runs is the actual behavior the bundle changes. That is a far more reliable way to understand it than reading the name "Doctrine Fixes," which is intentionally vague.

Implementation Patterns

Because the bundle is almost certainly a set of Doctrine fixes rather than a feature library, "usage" means integrating a patched Doctrine transparently.

Transparent decoration (the default pattern). Register the bundle and do nothing else. Your repositories, entities, and migrations code stays as-is. The bundle swaps a Doctrine service (typically something under doctrine.orm.*, doctrine.dbal.*, or the schema/migration tooling) for a corrected subclass or decorator. Verify the swap actually happened rather than assuming:

php bin/console debug:container doctrine.orm.entity_manager --show-private
# find the class name, then confirm it matches the bundle's src/ class

Gate it per environment. If the fixes only target dev/test schema tooling, register the bundle only there. Kernel::registerBundles() in config/bundles.php allows returning an array conditionally, and this prevents a dev-only patch from leaking into production Doctrine behavior.

Pin the Doctrine versions you tested against. The most common failure mode with a fixes bundle is that a Doctrine patch release makes a fix redundant or conflicting. Add explicit constraints in your root composer.json for doctrine/dbal and doctrine/orm and run composer why-not doctrine/dbal <version> to see the ceiling the bundle imposes.

Vendor-and-fork pattern (recommended at 2 stars / last release 2023-02-07). For a package with essentially zero dependents, the durable integration is:

composer require omasn/doctrine-fixes-bundle
# or, more safely:
# fork the repo, copy src/ into src/Vendor/DoctrineFixes/, and register the compiler pass yourself

Then wrap it with a test that locks in the behavior:

// tests/Doctrine/SchemaDiffTest.php
public function testSchemaIsInSync(): void
{
    $tool = self::$container->get('doctrine')->getManager()->getMetadataFactory();
    // assert schema:validate / migrations:diff produces no unexpected SQL
    $this->assertSame('', trim($this->runSchemaUpdateDumpSql()));
}

Integration tip — ordering with other Doctrine bundles. Compiler passes execute in priority order, and schema-tooling decorators are priority-sensitive. If you also use doctrine/doctrine-migrations-bundle or a schema-filter bundle, run debug:container --tag=... and confirm the decorator chain is what you expect. If the bundle's pass runs too early, register a tiny pass of your own with a higher priority that re-applies the decoration.

Gotchas and Tips

• This is an abandoned-adjacent package. Two stars, zero dependents, last release February 2023. Treat it as a reference implementation of Doctrine workarounds rather than a long-term dependency. Read the source, identify which upstream Doctrine ticket each fix corresponds to, and check whether current Doctrine already fixed it. If it has, remove the bundle and delete the pin.
• Silent no-op risk. A fixes bundle that decorates a service which no longer exists on your Doctrine version will not throw — the compiler pass just does nothing, or the decorator is bypassed. After every composer update, re-run the schema-diff baseline described in Getting Started.
• Cache is mandatory. Service decoration is compiled. bin/console cache:clear after install, after every Doctrine upgrade, and in CI before running schema tests. Stale dev caches are the #1 source of "the fix isn't working."
• DBAL vs ORM fixes are not interchangeable. doctrine/dbal 3.x changed the schema/type API significantly versus 2.x. Check which layer the bundle patches; a DBAL 2-era fix may be structurally impossible to apply on DBAL 3 and will appear to install fine while doing nothing.
• Conflict with doctrine:schema:update --force in production. If the bundle patches the schema comparator, a "fix" intended to stop spurious diffs may instead suppress real diffs. Never let schema:update --force and a schema-fixing bundle both run in prod — use migrations exclusively.
• Debugging a fix that stops working: use debug:container <service-id> --show-private to see the resolved class, then debug: autowiring / debug:container --tags. If the class is Doctrine's stock one, the decorator did not apply — check bundle registration order and Symfony version compatibility in composer.json.
• Extension points are thin. Expect no configuration tree, no events, and no service you can toggle. The effective extension point is subclassing the bundle's classes in your own src/, or a compiler pass that re-registers the decorator at a different priority. Plan for that rather than for config flags.
• Version constraints in your root composer.json are your safety net. Run composer outdated on Doctrine packages regularly. The moment Doctrine ships the upstream fix, this bundle becomes dead weight that can block upgrades via its composer.json constraints — check the ceiling before planning any DBAL/ORM major upgrade.