kabiroman/adaptive-entity-manager-bundle
Adaptive Entity Manager for Laravel offers a flexible, configuration-driven way to define, manage, and adapt Eloquent entities at runtime. Streamline CRUD, dynamic schemas, and relationships with a lightweight bundle built for extensibility and easy integration.
Architecture fit. The bundle is a Symfony-style service-integration layer (kabiroman/adaptive-entity-manager-bundle) wrapping kabiroman/adaptive-entity-manager. Release 3.1.0 is a dependency-alignment release rather than a feature release: it pins ^1.6 of the core library, which introduces value-object (VO) metadata that no longer requires ValueObjectInterface, adds ValueObjectAwareEntityManagerInterface, and tightens criteria/storage field metadata. For a Laravel/PHP service, this fits well where domain value objects (money, IDs, email, date ranges) are used as entity fields and you want a generic entity manager rather than hand-written repositories — the bundle supplies container wiring so application code gets a correctly constructed AdaptiveEntityManager without manual factory code. It is a poor fit for teams that expect thin, framework-idiomatic Eloquent/Doctrine models; the abstraction is opinionated and now leans further into metadata-driven VO handling.
Integration feasibility. Moderate-to-good. The upgrade is a single composer update kabiroman/adaptive-entity-manager-bundle in the normal case, with Composer resolving the transitive ^1.6 constraint. The real work is audit-driven: any application class that typehints EntityManagerInterface and calls VO helpers (getValueObjectRegistry(), hasValueObjectSupport()) must move to ValueObjectAwareEntityManagerInterface (or the concrete AdaptiveEntityManager). That is a mechanical but grep-driven change across the codebase and any first/third-party packages with the same typehint. Services resolved from the bundle remain AdaptiveEntityManager, so container autowiring is largely unaffected.
Technical risk. Medium-low, but non-trivial for two reasons. First, the constraint bump to ^1.6 means the core library's "stricter field metadata" validation will now reject entity/VO field definitions that previously passed silently — a latent-configuration failure that surfaces at boot, hydration, or first persist rather than at deploy. Second, dropping the ValueObjectInterface requirement is permissive (good) but changes the contract for code that relied on that interface for polymorphism, instanceof checks, or custom serializers. The interface-split (EntityManagerInterface vs ValueObjectAwareEntityManagerInterface) is the intended safety valve, but teams that typehint the base interface and call VO methods will get runtime method not found/type errors rather than a compile-time failure. Risk is concentrated in: static analysis coverage, test suites that mock EntityManagerInterface, and any code paths without VO unit tests.
Key questions.
EntityManagerInterface anywhere that also invokes VO helpers? (Blocking for the upgrade.)ValueObjectInterface?ValueObjectAwareEntityManagerInterface autowires in Laravel's container, or do we rely on the concrete class?^1.6 compatible with our PHP and framework baseline (Laravel/Symfony versions, composer.json platform config)?Stack fit. Composer-native, PSR-4, framework-agnostic core with bundle wiring — it composes cleanly with a Laravel app that already uses service providers and the container. Where the app is Eloquent-centric, treat this as a bounded-context tool for domain-heavy modules rather than a replacement ORM; where the app already uses AdaptiveEntityManager directly, the bundle is the correct integration surface and 3.1.0 keeps that surface stable.
Migration path. (1) Bump the constraint in a branch and run composer update kabiroman/adaptive-entity-manager-bundle; confirm resolution to core 1.6.x. (2) Grep for EntityManagerInterface and getValueObjectRegistry|hasValueObjectSupport; identify intersections, including test mocks and fixtures. (3) Change those typehints to ValueObjectAwareEntityManagerInterface (or AdaptiveEntityManager), and add a container binding/alias so the interface autowires where needed. (4) Replace any ValueObjectInterface instanceof/serializer coupling with explicit field metadata or per-VO serializers. (5) Fix metadata validation errors surfaced by 1.6 by running the test suite and a boot/container smoke test.
Compatibility. Assume a semver-minor bump with a de facto behavioural breaking edge (stricter metadata, interface split). Treat 3.1.0 as requiring a code review rather than a fire-and-forget update. Downstream packages pinning adaptive-entity-manager ^1.4/^1.5 will conflict; inventory transitive dependents before merging. No runtime requirement changes are stated, but verify PHP/framework baselines against core 1.6.
Sequencing. Do the dependency bump and typehint migration in one PR behind CI with static analysis enforced; land it before any feature work that touches VO fields. Roll out to a non-production environment first for a hydration/persist smoke pass, then production. If the app is large, split: (a) dependency + interface typehints, (b) metadata corrections, (c) removal of ValueObjectInterface coupling — so a failure localises.
Maintenance. Low ongoing cost — this is a wiring package tracking a core library. The 3.1.0 pattern (core version bumps arriving with interface/documentation changes) suggests routine quarterly-ish dependency churn; budget a standing maintenance window for composer outdated on this pair and keep the two packages version-locked.
Support. Upstream is a small maintainer ecosystem; expect community support rather than enterprise SLAs. Mitigate by recording the exact version pair in the lockfile, pinning, and keeping the upgrade notes in the repo so the interface split is documented for the team. The release notes' explicit guidance ("use ValueObjectAwareEntityManagerInterface or AdaptiveEntityManager") is the support artifact to circulate.
Scaling. Unchanged by this release — 3.1.0 is not a performance release. Stricter metadata validation has a marginal startup cost but improves predictability. Scaling characteristics remain those of the core entity manager (metadata resolution and hydration cost per entity); if VO-heavy entities become a hotspot, profile hydration before optimising.
Failure modes. (1) Runtime type error on VO helper calls via EntityManagerInterface — most likely, caught by tests. (2) Boot-time or first-persist failure from stricter field metadata — catches configuration drift but can reach staging/prod if smoke tests are thin. (3) Composer dependency conflict with pinned transitive dependents — caught at install. (4) Silent contract loss where code relied on ValueObjectInterface — least likely to be caught automatically; requires code review. (5) Mock/test drift where EntityManagerInterface is stubbed for VO methods.
Ramp-up. Low for engineers already on the bundle; the concepts are container wiring plus two interfaces. New joiners need a short primer on the interface split (EntityManagerInterface vs ValueObjectAwareEntityManagerInterface) and on declaring VO field metadata; a one-page internal note plus the upstream release notes is sufficient. Estimated effort for the upgrade on a mid-size codebase: half a day to a day and a half, dominated by the typehint audit and metadata fixes.
How can I help you explore Laravel packages today?