chore(cohorts): drop the superseded profile-keyed summary MVs - #468
chore(cohorts): drop the superseded profile-keyed summary MVs#468niajkitir wants to merge 1 commit into
Conversation
Migration 20 replaced profile_event_summary_mv and profile_event_property_summary_mv with pairs keyed for the queries that read them, migration 21 filled those with history, and cohort.service has read the new tables since Openpanel-dev#458. The old pair was left in place so the change stayed revertible by pointer while the new tables were verified. Nothing reads them now, so they are two MV triggers firing on every event insert with no consumer. Drop them. delete.service stops naming them, which it has to: an ALTER ... DELETE against a dropped table is UNKNOWN_TABLE, so leaving those entries would break project deletion. Their TABLE_NAMES entries stay, annotated, because migrations 13, 14 and 15 still reference them. Clustered installs carry two objects per MV, `<name>` Distributed and `<name>_replicated` the view. The Distributed table is dropped first so nothing can route a read at a view mid-drop, and dropping the view takes its implicit `.inner_id.<uuid>` storage with it. Verified on standalone 26.1.3 and a keeper-backed 2-shard cluster 25.3, each built from an empty database through migration 21 first: both MVs and their inner tables are gone on every node, cohort reads still resolve from either node, ingestion continues, a second run is a no-op, and every statement delete.service now emits is accepted against the post-drop schema. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe PR adds migration 23 to drop two superseded ClickHouse materialized views. Clustered installations drop Distributed and replicated objects. Non-clustered installations drop the tables only. Project deletion no longer targets these views, while legacy migration references remain documented. ChangesSuperseded cohort summary views
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: 🟡 Moderate · up to This PR removes two legacy cohort-summary views and stops project deletion from targeting them. Merge readiness is currently moderate because a standalone/cluster configuration mismatch could leave replicated views and stored data outside the deletion lifecycle, while dry-run execution can still perform irreversible drops. Sequence Diagram(s)sequenceDiagram
participant Migration as migration 23
participant ClusterConfig as getIsCluster
participant ClickHouseRunner as runClickhouseMigrationCommands
Migration->>ClusterConfig: read cluster mode
Migration->>ClickHouseRunner: execute cluster-specific drop commands
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Follow-up to #458, as discussed.
Why now
#458 replaced
profile_event_summary_mvandprofile_event_property_summary_mvwith pairs keyed for the queries that actually read them (migration 20), filled those with history (migration 21), and pointedcohort.serviceat the new tables.The old pair was deliberately left in place and kept receiving inserts, so the change stayed revertible by pointer while the new tables were verified. Nothing reads them now, so all they do is fire two extra MV triggers on every event insert for no consumer. This drops them.
What changes
23-drop-old-cohort-summary-mvs.tsdrops the two views.delete.servicestops naming them. That part isn't cosmetic:ALTER TABLE ... DELETEagainst a dropped table isUNKNOWN_TABLE, so leaving those entries would break project deletion. Confirmed against the post-drop schema:Their
TABLE_NAMESentries stay, with a comment saying why: migrations 13, 14 and 15 still reference them and have to keep compiling. Happy to inline the literals in those three and remove the constants instead, if you'd rather not carry them.Clusters
A clustered install has two objects per MV:
<name>is the Distributed table and<name>_replicatedis the view itself. The Distributed table is dropped first so nothing can route a read at a view that's mid-drop. Dropping the view takes its implicit.inner_id.<uuid>storage with it, so there's no third name to clean up (verified: inner table count goes 8 → 6 on both nodes).Testing
Standalone ClickHouse 26.1.3 and a keeper-backed 2-shard cluster on 25.3, each built from an empty database through migration 21 before dropping.
delete.serviceemitsOne-way
No
down(). The aggregated history goes with the tables, and rerunning migrations 13 and 14 would only bring back empty structure, so adown()here would be a rollback in name only. The header notes where the definitions live if anyone ever needs them back.Unrelated, but worth flagging
maincurrently has duplicate migration numbers:20-cohort-summary-mv-sort-keyalongside20-invite-project-access-levels, and21-backfill-cohort-summary-mvsalongside21-wind-down-onboarding-pointer.migrate.tssorts on the numeric prefix, so ties fall back toreaddirSyncorder, which is filesystem-dependent. Harmless for these pairs since they're independent, but it's a latent ordering hazard. I numbered this one 23 to stay clear of22-add-events-inserted-at.🤖 Generated with Claude Code
Summary by CodeRabbit