- Can I use opifer/eav-bundle in a Laravel application?
- No. It is a Symfony bundle built on Symfony's Bundle and DependencyInjection lifecycle plus Doctrine ORM, and there is no Laravel bridge. Adopting it in Laravel means running a second ORM and persistence paradigm alongside Eloquent, which is a much bigger commitment than the custom-fields feature itself.
- Is opifer/eav-bundle maintained?
- No. The repository is archived, the last release was 2016-01-13, and it has roughly 10 stars and zero dependents. There is no CVE response path, no community pressure-testing, and no one to escalate compatibility defects to.
- Does opifer/eav-bundle support Laravel 11 and PHP 8.1+?
- No. It targets Symfony 2.x and early 3.x bundle APIs, Doctrine ORM around the 2.4 era, and PHP 5.5 through 7.0. It will not resolve on PHP 8.1+ without patching Composer constraints, and conflict against Laravel 10 or 11 dependency trees is near-certain.
- What is opifer/eav-bundle used for?
- It implements the Entity-Attribute-Value pattern for Symfony applications, letting you attach dynamically defined attributes to Doctrine entities without changing the schema. It provides attribute and attribute-set definitions with typed value storage, and later revisions of the project line included an administration surface for managing those definitions.
- Does opifer/eav-bundle work with Eloquent models?
- No. Its persistence layer is Doctrine ORM mappings, not Eloquent, and it does not participate in Laravel's service container, package discovery, or facades. Using it would require maintaining a Doctrine entity layer beside your Eloquent models.
- What are the best alternatives to opifer/eav-bundle for Laravel?
- Use JSON or JSONB columns with Laravel's casts and a schema registry in application code; that covers most custom-field requirements without a pivot-per-attribute model. If you truly need typed, indexed arbitrary attributes, build a clean-room EAV implementation on Eloquent rather than forking abandoned code.
- Should I use EAV or JSON columns for custom fields in Laravel?
- Prefer JSON columns. EAV degrades into N self-joins per predicate when you filter or sort across arbitrary attributes, while JSON columns are natively supported by MySQL and Postgres and by Laravel's json casts. EAV is over-engineered if attributes are write-mostly and read back as a blob.
- Is opifer/eav-bundle safe for production?
- Treat it as a reference design, not a production dependency. An archived package with zero dependents has no community pressure-testing and no patch path, so any defect you hit becomes your defect. The known EAV trade-offs of query complexity, type-coercion ambiguity, and unenforceable referential integrity add further risk.
- How do I install opifer/eav-bundle?
- Installation would be a Composer require of opifer/eav-bundle, but it is not viable on a modern Laravel or PHP stack because of Symfony, Doctrine, and Composer constraint conflicts. The recommended path is to read the source for its attribute and value modelling instead of installing it as a dependency.
- What are the trade-offs of the EAV pattern?
- Schema-free flexibility is paid for with query complexity, because filtering on multiple attributes requires one join per predicate. Type coercion is ambiguous without a strict metadata registry, and the database cannot enforce referential integrity for attribute values. Row counts in the value table also scale as entities multiplied by attributes, which drives your indexing and read-model decisions.