Weave Code
Doctrine Auditable Bundle Laravel Package
gtt/doctrine-auditable-bundle
GTT Doctrine Auditable Bundle for Symfony automatically tracks entity changes in Doctrine, recording inserts, updates, and deletes with user and timestamp metadata. Easily configure audited fields and review a reliable audit trail for compliance, troubleshooting, and data integrity.
gtt/doctrine-auditable-bundle adds transparent audit logging to Doctrine entities in Symfony applications. Built on the Doctrine Auditable extension, it automatically tracks create, update, and delete operations, recording who changed what, when, and which fields were affected—without polluting your domain code or requiring manual event listeners.
- Automatic tracking of entity inserts, updates, and removals
- Field-level change history with old and new values
- Configurable actor resolution for identifying the current user
- Seamless Symfony integration via bundle configuration
- Queryable audit records for reporting and compliance
Ideal for applications requiring traceability, compliance, or reliable change history.
Frequently asked questions about Doctrine Auditable Bundle
- Can I use gtt/doctrine-auditable-bundle in a Laravel application?
- Not directly. This is a Symfony bundle built on Doctrine ORM's event system: it ships a bundle class, a DI extension with a configuration tree, and Doctrine event subscribers, none of which Laravel exercises natively. Making it work would require laravel-doctrine/orm plus manual bundle bootstrapping, meaning you would run it in a mode its maintainers likely never tested. If your application is Eloquent-based, evaluate OwenIt/Laravel-Auditing instead; only consider this package if you are on Symfony with Doctrine, or already committed to Doctrine in Laravel.
- How do I install and register gtt/doctrine-auditable-bundle in a Symfony app?
- Install it with Composer and register the bundle in your kernel or config/bundles.php depending on your Symfony version, then add the bundle's configuration block to your config files. The bundle wires its audit listener through the Symfony DI extension, so the audit entity mapping and blame resolver are configured through the config tree rather than in code. Because the last tagged release was April 2022, verify the composer.json version constraints against your Symfony and Doctrine versions before installing. Run a throwaway branch first and confirm audit rows appear for a create, update, and delete before merging.
- Which Doctrine ORM and Symfony versions does this bundle support?
- The most recent release dates to 2022-04-04, and there is no indication of Doctrine ORM 3.x or PHP 8.2+ attribute-mapping support. Doctrine 3 removed the annotation driver and tightened event APIs, so a 2022-era onFlush listener is a plausible breakage point. Check the composer.json constraints and whatever CI matrix exists rather than assuming compatibility. If you need ORM 3, plan to fork and patch the listener or pick a maintained alternative.
- Does it audit collection and association changes, or only scalar field updates?
- The underlying mechanism is an onFlush listener that inspects the UnitOfWork change sets, which reliably captures scalar field diffs. Collection deltas typically require recomputing changes after computeChangeSets, and insert-then-update sequences within a single flush, hard deletes, and inverse-side-only changes are commonly missed or mis-recorded by listeners of this style. DQL UPDATE and DELETE statements plus raw SQL bypass listeners entirely and will produce silent audit gaps. Confirm the actual behavior with integration tests covering each of those cases before relying on it for compliance.
- How does the bundle know which user made a change?
- The blame resolver is presumably bound to Symfony's TokenStorageInterface, so the acting principal comes from the security token. That is wrong or empty in console commands, queue workers, and impersonation flows, where there is no request-scoped user. Audit rows should carry an explicit source or actor that you set deliberately rather than inferring it from request state. Verify the resolver is overridable through the container before you design around it.
- Will the audit listener recurse or insert duplicate audit rows?
- Audit entity persistence has to use a dedicated EntityManager or be explicitly excluded from the listener, otherwise persisting an audit record triggers the listener again. This is the classic failure mode for onFlush-based auditing and it is not something to discover in production. Ask the maintainer, or read the subscriber code, to confirm which approach is used. If neither safeguard exists, budget the work to add one.
- Is the audit write part of my domain transaction?
- This determines your failure semantics and you need an explicit answer before adopting the package. If audit rows are written on the same EntityManager, they are atomic with the domain change but vanish when the transaction rolls back. If they use a separate EntityManager, the trail survives a rollback but can record changes that never committed. Decide which behavior your compliance requirements demand and test it.
- What storage format does it use, and is there a read-side API?
- Expect schema-only output: audit tables written by the listener, with no query or reporting layer included. The payload is likely serialized PHP rather than JSON, which is awkward to query and unsafe to unserialize from untrusted sources. Confirm the column types and encoding before you plan any reporting on top of it. If you need searchable history, you will be building the read side yourself or changing the encoding.
- Does it include retention, partitioning, or pruning tooling?
- No retention or pruning tooling is described in the package. Audit tables grow with every write, so on a busy entity you will need partitioning, archival, or scheduled deletion from day one. Because the schema is created by the bundle's mapping, plan your partitioning strategy before the table gets large. Treat pruning as unbudgeted work in your estimate.
- Is gtt/doctrine-auditable-bundle maintained and safe for production?
- Treat it as an internal extraction rather than a supported open-source product: roughly 5 stars, 0 dependents, and no third-party validation. Assume no security response process, no CVE triage, and no roadmap, and expect external pull requests may go unreviewed. If you adopt it, vendor a fork you control, pin the version, and add your own integration tests around the onFlush listener. For a new build, compare the cost of forking against writing a small subscriber yourself.
Weaver
How can I help you explore Laravel packages today?