feat(clickhouse): extend retention TTL to the events_daily table

[levivannoort]

What

Follow-up to #24. Generalizes applyEventsRetention() into applyRetention(string $tableName) and applies the same retention window to both the raw *_events table and the aggregated *_events_daily table. Gauges remain untouched.

Why

The raw events TTL alone left the aggregated events_daily table unbounded. Callers that set a retention window now get a single consistent horizon across both tables, so long-term aggregated rows are purged on the same schedule instead of growing forever.

Changes

• setup() now calls applyRetention() for the events table and the events_daily table.
• Constructor/method docblocks updated to reflect events + events_daily (gauges excluded).
• Schema test renamed to testRetentionAppliesTtlToEventsAndDailyTables; asserts events_daily now carries the TTL and gauges does not.

Note

This is a behavior change: with a retention set, aggregated daily history is now bounded by the same window. Consumers relying on events_daily as unbounded long-term history should account for this.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR applies the ClickHouse retention window to aggregated daily events as well as raw events. The main changes are:

• Generalized the retention helper to accept a table name.
• Applied retention to both events and events_daily during setup.
• Updated schema coverage to expect TTL on daily events and no TTL on gauges.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
src/Usage/Adapter/ClickHouse.php	Generalizes retention application and applies the same TTL to the daily aggregate table.
tests/Usage/Adapter/ClickHouseSchemaTest.php	Updates the retention schema test to cover events, daily events, and gauges.

_{Reviews (1): Last reviewed commit: "feat(clickhouse): extend retention TTL t..." | Re-trigger Greptile}