Loggastic 2.1.0 puts the 2.0 storage abstraction to work: you can now run activity logs entirely on your relational database, with no Elasticsearch cluster required.
Choose your storage
A new storage config option selects the backend in one line:
# config/packages/loggastic.yaml
locastic_loggastic:
storage: doctrine # 'elasticsearch' (default), 'doctrine' or 'in_memory'The default stays elasticsearch, so existing apps upgrade with no changes. When another backend is selected, no Elasticsearch services are registered at all: no ES client, no elastic_* configuration, no PSR-18 requirement.
Doctrine DBAL storage (#45)
Activity logs and current data trackers are stored in two shared database tables with JSON columns, discriminated by an indexed object class column. The schema is created through the DBAL schema API and all values pass through DBAL type conversion, so the adapter runs on PostgreSQL, MySQL, SQLite and anything else Doctrine DBAL supports, on both DBAL 3.8+ and 4.x (both majors are covered in CI). Timestamps are normalized to UTC, table names are overridable via service configuration, and tracker writes are upserts, so message retries or re-running the populate command never create duplicate tracker rows.
In-memory storage (#45)
storage: in_memory keeps logs in the PHP process while mirroring real backend semantics (sorting, pagination, per-class isolation). Test suites can exercise the full logging flow with zero external services.
Everything else
doctrine/dbal(^3.8 || ^4.0) is now an explicit dependency- README gained a "Choose your storage" section and a documented
storagekey in the configuration reference
Full details in CHANGELOG.md. No breaking changes; upgrading from 2.0.0 is a plain composer update locastic/loggastic.