- Can I use dmytrof/doctrine-modification-events-bundle in a Laravel application?
- Not as a drop-in dependency. It is a Symfony bundle that registers itself in config/bundles.php and hooks Doctrine ORM's unit of work, so a stock Laravel app has no service provider, facade, or config entry to load it. Making it work would mean booting a Symfony kernel and pulling Doctrine into your stack, which is high effort for little gain. Adopt the pattern instead: Eloquent Observers plus DB::afterCommit plus queued listeners gives you the same behavior with first-party tooling.
- What does dmytrof/doctrine-modification-events-bundle actually do?
- It lets a Symfony 7/8 application dispatch an application event whenever a Doctrine entity is modified. Internally it subscribes to Doctrine's unit-of-work lifecycle (preUpdate, postUpdate, postFlush) and turns those hooks into events your own listeners can handle. That makes it useful for audit trails, cache invalidation, notifications, or external sync triggered by entity changes.
- How do I install and enable the bundle in Symfony?
- Run composer require dmytrof/doctrine-modification-events-bundle, then register Dmytrof\DoctrineModificationEventsBundle\DmytrofDoctrineModificationEventsBundle::class => ['all' => true] in config/bundles.php. There is no separate configuration step documented beyond that. After enabling, you write listeners or subscribers that react to the modification events it dispatches.
- How do I get the same entity-modification events in Laravel with Eloquent?
- Use Eloquent Observers to capture the change set, Model::getChanges() to read before/after field values, and DB::afterCommit() to defer dispatch until the transaction is safely committed. Push the actual work into a queued listener implementing ShouldQueue so slow side effects never block the request. This is a few days of work and uses only documented, first-party Laravel features your team already knows.
- Which PHP, Symfony, and Doctrine versions does this bundle support?
- The package pins PHP ^8.4, Symfony 7/8, Doctrine ORM ^3.5, and DoctrineBundle ^3.0. Those are narrow constraints, so upgrading any of those components can force a coordinated upgrade of the bundle. Verify the constraints in composer.json against your current runtime before planning anything around it.
- Does the bundle dispatch modification events before or after the database transaction commits?
- It hooks Doctrine's preUpdate, postUpdate, and postFlush lifecycle, so dispatch behavior is tied to flush and transaction boundaries rather than to your own commit point. The release history shows repeated churn around duplicate dispatch and forced flush, including the introduction of ForceFlushPreviousModificationsInterface in v1.5.3. That is a strong signal that flush semantics are genuinely subtle here. Whatever approach you take, test rollback and nested-transaction scenarios explicitly.
- Is dmytrof/doctrine-modification-events-bundle safe to depend on in production?
- The maturity signals are weak: zero stars, zero dependents, a single maintainer, and only a README plus release notes as documentation. Because there are no dependents, there is no fork ecosystem or downstream pressure if maintenance stops. Combined with tight version pins, that is a meaningful bus-factor and upgrade-coupling risk. If you must use it, vendor or fork it and assign a clear owner.
- Is there a Laravel package that provides Doctrine modification events out of the box?
- No first-party Laravel equivalent exists, because Laravel's native answer to this problem is model events and Observers. If you genuinely want Doctrine in Laravel you would add laravel-doctrine/orm first, then port the dispatch logic from this bundle into Laravel's container and event system. That path rewrites your repository and entity layer, so only take it with a broader strategic driver such as sharing a domain layer with a Symfony service.
- Should I track field-level changes or just entity-level 'something changed' notifications?
- Decide this before writing any code, because it drives the whole design. Auditing and external sync usually need before/after values, which in Laravel means Model::getChanges() and getOriginal() inside the Observer. Simple cache invalidation or notification triggers often only need a single update event. The bundle's modification-event model is the entity-level style, so field-level needs may exceed what it gives you.
- How should I evaluate and test this bundle before committing to it?
- Run a one-to-two day spike: read the bundle's subscriber internals, then prototype the equivalent Observer plus afterCommit plus queued event on one high-value entity such as User or Order. There is no Laravel test coverage or documentation, so every behavioral question has to be answered by reading source and writing your own tests. Compare developer effort and behavioral parity against the native Laravel approach. Set a clear decision gate so the spike does not quietly turn into a migration.