Weave Code
Doctrine Discriminator Bundle Laravel Package
levelab/doctrine-discriminator-bundle
A Symfony bundle that simplifies Doctrine discriminator mapping for entity inheritance, reducing boilerplate when configuring discriminator maps. Useful for single-table inheritance setups and cleaner Doctrine configuration in Symfony applications.
Symfony-ready Doctrine DiscriminatorMap extension, which allows to move mapping from superclass to subclasses
Frequently asked questions about Doctrine Discriminator Bundle
- Can I install levelab/doctrine-discriminator-bundle in a Laravel application?
- No. It is a Symfony bundle extending Symfony\Component\HttpKernel\Bundle\Bundle with a DI extension, and Laravel has no bundle registration or package discovery for it. There is no service provider and no supported install path; forcing it with --ignore-platform-reqs drags a parallel Symfony kernel in for no benefit. In Laravel you should reimplement the roughly 200-line mechanism as a Doctrine event subscriber instead.
- What does levelab/doctrine-discriminator-bundle actually do?
- It decentralizes Doctrine's discriminatorMap for single-table inheritance so each subclass declares its own discriminator value instead of the root entity naming every subclass. A loadClassMetadata event subscriber plus a Symfony compiler pass synthesizes the map at metadata-build time. That removes the base class as a shared registry that every team must edit when adding a subtype.
- Is levelab/doctrine-discriminator-bundle still maintained?
- No. The last release was 2016-03-03, the repository has around 12 stars and zero dependents, and there are no tests, CI pipeline, or security process. There is no compatibility matrix and no issue triage. Treat it as abandoned code and a design reference only.
- Does it support PHP 8 and Doctrine ORM 3?
- No. It targets PHP roughly 5.5 to 7.0 signatures and Doctrine ORM 2.5-era APIs, including the doctrine/annotations reader. PHP 8 will likely trigger deprecations and fatals inside the subscriber and compiler pass, and Doctrine 3's shifted listener surface plus PHP 8 attributes are unsupported. On PHP 8.1+ with Doctrine 3.x the correct answer is reimplement, not integrate.
- How do I get decentralized discriminator maps in Laravel?
- Use laravel-doctrine/orm for Doctrine ORM, then write a class implementing Doctrine\Common\EventSubscriber that listens on loadClassMetadata. On the root entity, discover subclasses carrying a PHP 8 attribute such as #[DiscriminatorValue('foo')] from a declared namespace or cached class list, then set the metadata discriminatorMap and subClasses properties. No Symfony kernel coupling is required.
- Which Laravel and PHP versions does this package support?
- None officially. It is packaged for Symfony 2.x and 3.x kernels running PHP around 5.5 to 7.0, with no Laravel service provider or package discovery. No compatibility matrix exists for Laravel 9, 10, 11, or 12. Any claim of Laravel support would be untested and unsafe to rely on.
- What is a Doctrine discriminator map and why would you decentralize it?
- In single-table inheritance, Doctrine requires the root entity to declare a discriminatorMap array naming every subclass, which turns the base class into a shared registry. Decentralizing means each subclass declares its own discriminator value and the map is assembled at metadata-build time. That decoupling matters when external packages register subtypes without editing core entities. If you have fewer than about five subclasses and a single team, the explicit map is cheaper and clearer.
- What are the production risks of using this bundle?
- Metadata interception is the highest-blast-radius place to inherit unmaintained code, and there are no tests establishing behavioral guarantees. The expensive failure mode is not a clean install error but a partial install where the subscriber intermittently fails to populate the map, surfacing as ClassNotFound or hydration errors only for subclasses loaded after the metadata cache warms. That produces data-integrity bugs rather than clean stack traces.
- What are the alternatives to this Symfony bundle for Laravel developers?
- Three realistic options: keep Doctrine's explicit discriminatorMap, reimplement the subscriber pattern natively inside your Laravel app, or refactor away from single-table inheritance if the subtype count is small. Doctrine's own PHP 8 attributes and laravel-doctrine/orm cover the remaining mapping needs. There is no maintained Laravel package that replicates this exact behavior.
- How much work is a clean-room reimplementation of the mechanism?
- Roughly 150 to 250 lines and 4 to 7 engineering days for a scoped version: a loadClassMetadata subscriber, a discriminator value attribute, and subclass discovery from a namespace or cached class list. Skip the Symfony bundle and DI extension entirely. Add tests around map population and metadata cache warm-up, because that is exactly where the original is weakest, and assign a named engineer as owner.
Weaver
How can I help you explore Laravel packages today?