- Is joschi127/doctrine-entity-override-bundle a Laravel package?
- No. It is a Symfony bundle that registers compiler passes and hooks Doctrine ORM metadata loading through Symfony's dependency injection container. It will not install or boot as a normal Laravel package. In Laravel it is only conceptually relevant if you run Doctrine ORM via laravel-doctrine/orm, and even then you would need custom wiring.
- Can I use doctrine-entity-override-bundle with Laravel and laravel-doctrine/orm?
- Not directly. The bundle depends on Symfony bundle registration and container wiring, while laravel-doctrine/orm uses a Laravel service provider and its own Doctrine bootstrap. The portable part is the metadata substitution idea: an event subscriber or metadata driver that rewrites resolved class names. You would need to rebuild that logic in Laravel rather than require this package.
- How does the bundle override Doctrine entities using inheritance?
- You configure pairs that map an original entity class to your own subclass. The bundle hooks Doctrine metadata loading and substitutes the original class name with the override during resolution, so mappings, repositories, and associations can resolve to your class. Your replacement class must extend the original entity and remain mapping-compatible. Hardcoded FQCNs in DQL or vendor code can still bypass the substitution.
- How do I install and configure doctrine-entity-override-bundle?
- In a Symfony app you install it with Composer, register the bundle in config/bundles.php, and add original-to-override class pairs in the bundle configuration. Each override class should extend the vendor entity and preserve its mapping strategy. This is Symfony-specific configuration; Laravel has no equivalent bundle registration step.
- Does it support Laravel 10/11, PHP 8.2, and Doctrine ORM 3?
- There is no Laravel support at all, so Laravel 10 or 11 compatibility is not applicable. The last release was in 2019, which predates PHP 8 attributes, Doctrine ORM 3.x, and modern Symfony versions. Expect incompatibility or version constraints on a modern stack. Validate against your exact PHP, Doctrine, and metadata driver before considering it.
- What are the risks of overriding vendor entities with inheritance?
- Associations with targetEntity hardcoded to the original FQCN, DQL or query builder references, and vendor type hints can bypass the override. Changing the inheritance mapping strategy can also produce schema-tool and migration diffs. These are runtime and production-data risks, not install-time errors. Prefer a supported vendor extension point or interface-based substitution when possible.
- How should I test Doctrine entity overrides before deploying?
- Start by asserting that Doctrine metadata resolves the override class for every mapped entity and association. Run schema validation and migration diffs against a production-like database. Add integration tests for repositories, DQL queries, and any vendor code that type-hints the original class. Also test serialization and identity checks such as instanceof.
- What are alternatives to this bundle for swapping Doctrine entities?
- Doctrine's ResolveTargetEntityListener substitutes interfaces rather than concrete parent classes, which is often a safer contract. Vendor-provided extension points, mapped superclasses, or dependency injection to replace a collaborator can avoid touching persistence metadata. If you truly need concrete entity substitution, forking the small metadata-substitution logic into your own codebase is more maintainable than depending on an abandoned bundle.
- Is doctrine-entity-override-bundle still maintained and safe for production?
- The last release was 2019-10-05, with very low adoption and no downstream dependents absorbing upgrade pain. That makes every incompatibility with modern PHP, Doctrine, or Symfony your responsibility. It is best treated as reference material rather than a production dependency. If you adopt the approach, fork and own the substitution code.
- Can I reproduce the entity override logic in a Laravel service provider?
- Yes, the core idea is portable PHP even though the Symfony container wiring is not. Register a Doctrine event subscriber or metadata driver in your Laravel Doctrine bootstrap that rewrites resolved class names during metadata loading, driven by a config array of original-to-override pairs. Keep the substitution narrow, test associations and DQL carefully, and prefer interface-based resolution if it satisfies the requirement.