- Can I install evozon-php/entity-extend-bundle in a Laravel application?
- No, not in any usable way. This is a Symfony bundle that depends on Symfony bundle registration, dependency injection compiler passes, and Doctrine ORM metadata listeners. It provides no Laravel service provider, no config publishing, and no Eloquent integration. Composer may resolve the package, but making it work in Laravel would require a substantial custom port rather than normal installation.
- What does EntityExtendBundle actually do?
- It is a Symfony bundle for extending Doctrine entities with additional fields without modifying their original classes. You configure extra attributes, persist their values through Doctrine listeners, and use them alongside existing entity data. The approach is closer to runtime entity augmentation or an EAV-adjacent pattern than to standard Laravel migrations.
- Does this package support Laravel Eloquent models?
- No. The package targets Doctrine ORM entities and relies on Doctrine metadata drivers and event listeners, not Eloquent. Using it in Laravel would mean adopting laravel-doctrine/orm and then reimplementing the bundle's Symfony-specific compiler passes and listeners. For most Laravel applications, that is not a practical integration path.
- Which Symfony and Doctrine ORM versions does this bundle support?
- The bundle is tightly coupled to specific Symfony and Doctrine ORM major versions, so you must check its composer.json constraints against your production stack. Changes in Symfony 4 to 5 to 6 and Doctrine ORM 2 to 3 touch metadata drivers, event listeners, and attribute mapping, which are exactly the surfaces this package depends on. Expect breakage on major upgrades unless the fork is patched.
- Is evozon-php/entity-extend-bundle maintained and safe for production?
- Treat it with caution. It has no observable adoption, no dependents, and is a one-person fork with undocumented divergence from the upstream package. Maintenance and version-coupling risks are high, and a low-visibility dependency with broad ORM interception privileges carries medium supply-chain risk. It is especially risky if schema-migration determinism is a hard requirement.
- How is this different from pjarmalavicius/PjEntityExtendBundle?
- It is described as a slight variation of the original PjEntityExtendBundle. The exact divergence is not documented, so patches may never be upstreamed and upstream fixes may never be merged. Evaluate both repositories and compare their composer constraints, open issues, and commit history before choosing one.
- What are Laravel-friendly alternatives for adding custom fields to entities?
- For Laravel, consider JSON or jsonb columns with castable value objects for sparse custom fields, which are simple and indexable in MySQL 8 and PostgreSQL. Alternatively, use dedicated attribute or extension tables with entity_id, key, value_type, and value columns, or evaluate EAV-style packages if dynamic fields are central to the product. The right choice depends on whether you need per-tenant schema variation, plugin-style augmentation, or audited migration determinism.
- How do you install and configure EntityExtendBundle in Symfony?
- Install it with Composer, register the bundle in your Symfony kernel or bundles.php, and configure the entity extension mappings according to the bundle documentation. You must ensure Doctrine metadata drivers and event listeners are properly registered in the Symfony container. There is no Laravel-style configuration publishing or service provider setup.
- Will runtime entity extension cause Doctrine migration or schema drift problems?
- It can. Dynamic entity extension implies runtime class generation and mapping manipulation, which can produce schema and migration drift if not carefully controlled. Failures may appear as corrupted mappings or silent data loss rather than clean exceptions. If you need deterministic, auditable migrations for regulated data, runtime-generated mapping is likely disqualifying.
- How should I spike or test this package before adopting it?
- Treat it as a reference implementation for the dynamic entity extension pattern rather than a drop-in dependency. Run a feasibility spike inside a Symfony application using your exact Symfony and Doctrine versions, testing mapping, persistence, and upgrade behavior. For a Laravel codebase, do not port the package; port the pattern using JSON columns or extension tables instead.