Product Decisions This Supports
- Feature decision — customer-specific data models. The core capability (extending Doctrine entities with additional attributes at runtime, without new migrations per customer) is the classic enabler for "custom fields," "custom properties," or per-tenant schema flexibility. This is a real product decision: do we hard-code a fixed schema and make customers file tickets, or do we ship self-service extensibility?
- Build vs. buy (and buy vs. fork). Because this package is explicitly a slight variation of an existing bundle (
pjarmalavicius/PjEntityExtendBundle), the decision it best informs is whether to adopt a third-party extension mechanism, fork one, or build a thin internal abstraction over JSON/attribute storage. The existence of a fork-of-a-fork is a signal that upstream didn't meet someone's needs — worth investigating what, and whether that need matches ours.
- Roadmap sequencing. Extensibility is a platform-level investment that tends to land early in a B2B SaaS roadmap (before enterprise deals demand it) or late (after sales keeps losing to competitors with "custom objects"). This package's existence lets you ship the capability in weeks rather than a quarter, which changes when on the roadmap it becomes affordable.
- Use cases it plausibly serves: multi-tenant SaaS needing per-account fields on core entities; internal admin/CMS tools where ops staff define attributes; integration-heavy products where inbound third-party payloads carry varying fields; migration/legacy-bridge scenarios where old system attributes must map onto new entities.
- De-scoping decision. Adopting it also means not building a bespoke EAV layer, not asking customers to accept a fixed schema, and not paying for a commercial custom-fields service. That opportunity cost is the useful comparison, not the package's feature list.
Critical caveat for the decision record: this is a Symfony bundle built around Doctrine ORM, not a Laravel package. If our stack is Laravel/Eloquent, this is not adoptable as-is — the realistic decision becomes "port the pattern" or "choose a Laravel-native equivalent." That reframing alone may dominate the assessment.
When to Consider This Package
Consider it only when all of the following hold:
- The application is Symfony with Doctrine ORM, on PHP and Doctrine versions this bundle actually supports (verify against its composer constraints before anything else — zero stars and zero dependents means no one has validated compatibility with recent Symfony/Doctrine releases).
- You need admin-configurable attributes on existing entities and have concluded that per-customer migrations or a proliferation of nullable columns are worse.
- Your team is willing to own the code: fork it, pin it, add tests, and carry it forward. At 0 stars and 0 dependents there is effectively no community, no issue triage, and no security response — treat it as source code you are adopting, not a dependency you are consuming.
- The blast radius is contained: internal admin tooling, a bounded module, or a feature you could unwind. Do not put it on the critical path of core transactional data.
- You have measured the query and hydration cost of dynamically extended entities against your latency budget. Dynamic attribute schemes routinely surprise teams at scale.
Look elsewhere (or build) when:
- The stack is Laravel/Eloquent — the premise of the brief doesn't hold.
- You need LTS, security patching, or vendor accountability. A single-maintainer fork with no dependents fails procurement and security review in most regulated contexts.
- Query performance matters. Extension schemes that spread attributes across side tables make filtering, sorting, and reporting on custom fields expensive. If the roadmap includes "let customers build reports on custom fields," evaluate that path before committing.
- Schema evolution and data integrity are priorities — dynamic attributes typically sidestep foreign keys and typed columns, pushing validation into application code.
- You are comparing against JSON/
jsonb columns with a typed accessor layer, a maintained EAV bundle, or a commercial custom-fields product. Run that bake-off honestly; a 40-line JSON column plus validation is often the real competitor and often wins.
- Data portability matters. If customers will ever export or migrate, or if you'll need to promote a custom field to a first-class column later, ask up front how painful that is with this design.
How to Pitch It (Stakeholders)
For executives: This is a small, unmaintained open-source component that solves a familiar problem — letting customers add their own fields to our data model without custom engineering each time. Its strategic value is speed to an extensibility feature, not the code itself. But it carries meaningful ownership risk: no community, no support, no security process, and it doesn't fit a Laravel stack. The recommendation is therefore not "adopt," but "use it as a reference implementation and validate the approach" — confirm the pattern against our actual performance and compliance requirements, then decide between a small internal build and a maintained alternative. Treat it as a design input that could compress a quarter of platform work into a few weeks, with the caveat that we will own whatever we ship.
For engineering: It's a Symfony/Doctrine bundle for runtime entity extension, forked from PjEntityExtendBundle with minor changes. Zero stars, zero dependents, single maintainer. Before any code is written, we need three answers: (1) does it run on our Symfony/Doctrine/PHP versions, (2) what does it cost us in queries and hydration at our data volumes, and (3) how do we get a custom field back out again — promoted to a real column, exported, or deleted cleanly. If those come back acceptable, the cheapest plan is vendoring a pinned fork with our own tests behind an internal interface, so we can swap the mechanism later without touching product code.