Weave Code
Reconstitutor Laravel Package
rekalogika/reconstitutor
Rekalogika Reconstitutor is a PHP library for rebuilding objects from persisted data. It maps database rows or arrays to typed objects through a simple reconstitution API, helping keep persistence logic separate from domain models.
Provides a thin layer that sits above Doctrine events to help you reconstitute/hydrate your entities. It lets you augment Doctrine's hydration with your logic in a concise and expressive class.
Frequently asked questions about Reconstitutor
- Is rekalogika/reconstitutor a Laravel package?
- No. It is a Symfony bundle for the Doctrine ORM/ODM ecosystem, and it has no native Laravel service provider or Eloquent integration. On a stock Eloquent-only Laravel app there is no integration surface and it delivers no value.
- Do I need Doctrine ORM to use rekalogika/reconstitutor in Laravel?
- Yes. The package sits above Doctrine events and the UnitOfWork and transaction lifecycle, so it needs Doctrine ORM or ODM to hook into. If your Laravel app is Eloquent-only, treat this package as out of scope rather than something to adapt.
- How do I install and register rekalogika/reconstitutor in a Laravel application?
- Install it with composer require rekalogika/reconstitutor:^2.5, then wire its services manually. Laravel does not read Symfony bundles.php, so you need a service provider or the container exposed by laravel-doctrine/orm to register the package's event subscribers on the same EntityManager instances your app uses, including secondary connections. Budget real effort for this step, because it is the part most likely to be underestimated.
- When is rekalogika/reconstitutor actually useful in a Laravel app?
- It matters when Doctrine-managed entity state survives across transactions in the same process, such as Octane, Swoole, RoadRunner, queue workers, Messenger consumers, or long-running console commands. In a classic per-request PHP-FPM model the EntityManager is torn down each request, so the package is dead weight. Its purpose is preventing long-lived in-memory object graphs from silently drifting away from the database.
- Does rekalogika/reconstitutor replace Doctrine's hydration?
- It works alongside Doctrine rather than replacing it. Doctrine still performs hydration and manages the EntityManager, while the package lets you apply your reconstitution logic in a concise, dedicated class. Think of it as a thin hook layer you must bind correctly, not a replacement for your mappings.
- What changed in rekalogika/reconstitutor 2.5.0 and should I pin it over 2.4.0?
- Version 2.5.0 has no breaking changes and no new public API. It fixes two behavioral bugs in transaction-lifecycle handling: the begin-flush-clear-commit sequence and detaching entities mid-transaction. It also widens dependencies to allow Symfony 8. Pin 2.5.0 rather than 2.4.0, because 2.4.0 is unsafe in exactly those lifecycle paths.
- Which PHP, Doctrine, and Symfony versions does rekalogika/reconstitutor support?
- Verify three axes before committing: PHP version against the package constraint, Doctrine ORM 2.x versus 3.x or ODM versus ORM, and the Symfony component versions in the release constraints. 2.5.0 opens Symfony 8.x through constraint widening, which is forward compatibility rather than evidence of production validation on Symfony 8. There is no native Laravel version matrix, so Laravel compatibility depends on your wiring plus those constraints. Run composer why-not rather than trusting the release note.
- What are the production risks of using rekalogika/reconstitutor?
- Technical risk is medium. The package operates on Doctrine internals, so its correctness is only as good as its coverage of transaction orderings. Failures are silent: a stale entity can be written back to the database, or an entity can be left detached where code assumes it is managed, which surfaces as data corruption rather than an exception. The two lifecycle fixes in 2.5.0 show how subtle these paths are.
- How should I test a rekalogika/reconstitutor integration in Laravel?
- Unit tests will not catch this failure mode. You need integration tests that exercise real transaction orderings against a database, including begin, flush, clear, commit, and mid-transaction detach. Add soak tests for long-running worker processes so stale-entity and detached-entity problems surface before production.
- Is rekalogika/reconstitutor actively maintained, and what are the alternatives for Laravel teams?
- The 2.5.0 release shows active maintenance, but note that two silent correctness bugs in transaction-lifecycle handling were fixed in a patch release, so pin the package and watch it. If you use Eloquent, the safer alternative is not adopting it at all, because porting a Symfony and Doctrine design into a Laravel codebase without a Doctrine foundation is a warning sign. If you do run Doctrine in Laravel, weigh it against handling refresh and clear explicitly in your own code or recycling the EntityManager per job.
Weaver
How can I help you explore Laravel packages today?