- How do I install patchlevel/event-sourcing in a Laravel application?
- Install it with composer require patchlevel/event-sourcing, then follow the package documentation for service provider registration and configuration. The 3.x line targets Laravel 10 and 11 and requires PHP 8.2 or newer. Run your migrations and verify the event store schema before wiring up aggregates and subscriptions.
- Which Laravel and PHP versions does patchlevel/event-sourcing support?
- The 3.x line targets Laravel 10 and 11 and requires PHP 8.2 or newer. Check the Composer constraints for the exact minor you pin, because Laravel support can change across major releases. The library is built on Doctrine DBAL rather than Eloquent, so your Laravel version mainly affects integration wiring.
- Which databases can I use for the event store?
- It supports MySQL, PostgreSQL, MariaDB, and SQLite through Doctrine DBAL. The package officially supports the database versions listed in its documentation and tested in CI. For production, choose a database and version that appears in that supported matrix rather than relying on an untested variant.
- Do I have to use Eloquent for read models with this event sourcing package?
- No. patchlevel/event-sourcing is designed as the write model and event store, while read models can be built with Eloquent, query builders, or other persistence layers. Projections update those read models asynchronously, so you should plan for eventual consistency. This separation is useful in a modular monolith or bounded-context service.
- How do snapshots work in patchlevel/event-sourcing?
- The package includes an automatic snapshot system intended to improve aggregate rehydration performance. Snapshots reduce how many events must be replayed for large or long-lived aggregates. You should still test replay and snapshot behavior in staging before relying on it in production.
- What are projections and subscriptions, and how do I run them?
- Projections and processors are managed as subscriptions with a versioned lifecycle. Catch-up subscriptions read events from the store and update read models or trigger reactions. In Laravel you typically run subscription workers as background processes, using the package's Symfony-based CLI commands or your own scheduler and queue setup.
- How does crypto-shredding handle personal data in events?
- Crypto-shredding lets you encrypt personal data stored in events and later destroy the encryption keys so the data becomes unreadable. That supports erasure workflows without rewriting the entire event stream. You should design key management and retention carefully before storing regulated personal data.
- What is upcasting used for in this event sourcing library?
- Upcasting transforms older event payloads into the current event shape when they are read from the store. It lets you evolve event classes without rewriting historical events. This is especially useful when replaying long-lived streams after schema changes.
- What does stream splitting do?
- Stream splitting lets you divide a large aggregate's events across multiple streams. It helps control stream size and replay cost for aggregates that would otherwise grow very large. Use it deliberately, because it changes how you reason about aggregate boundaries and stream lookup.
- What changed with header aliases in patchlevel/event-sourcing 3.22.0?
- Version 3.22.0 adds header aliases for resolving event metadata headers stored under legacy or third-party names. This affects header resolution on the deserialization path, so confirm from the PR and upgrade guide whether aliases apply on read only or also normalize on write, plus precedence rules for collisions. Pin ^3.22, run your test suite, and exercise a full replay in staging before production.