feat(DENG-8178): search_clients_daily_glean_v1 - #9828
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
A changed query reads restricted / workgroup-gated data and writes it to a more broadly readable destination that no team owns: A source shown as This is advisory and does not block merge. |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
This PR adds search_derived.search_clients_daily_glean_v1 (query, schema, metadata, README), the user-facing view search.search_clients_daily_glean, a Glean client_id shredder target, and two query tests with shared source-schema fixtures. Nothing reads the table yet.
I checked the grain and the three-way full outer join for fan-out and null-key collapse and did not find a problem: join-1 output keys are unique, legacy_cte.partner_code is non-null by the 'unknown_code' sentinel, and the COALESCE(serp, sap) predicates on join-2 keep legacy-only keys one-sided rather than duplicating them. The date_partition_offset: -1 rationale matches how serp_events_v2 writes its partition, the metrics.url / metrics.url2 split is right (events_stream_v1's metrics_to_json moves url2 to $.url), NUMERIC matches mozfun.norm.browser_version_info, the shredder entry pairs with DESKTOP_GLEAN_SRC correctly, and schema.yaml field order matches final_cte's select list. Test coverage of the label shapes and the unknown_code orphan-ad path is good.
Four findings inline: two in the SERP/join logic, one convention violation on the SERP source reference, and one suggestion about the legacy tab-count aggregation. Per the reviewer checklist, the Bigeye monitor and backfill are deferred to post-merge per the PR description, and no backfill.yaml is touched here.
This comment has been minimized.
This comment has been minimized.
|
Sorry @Standard8 I hit the re-review button by accident. |
irrationalagent
left a comment
There was a problem hiding this comment.
fixes look good to me - thank you @kbammarito !
Integration report
|
Description
search_derived.search_clients_daily_glean_v1
A Glean-based daily search aggregate, one row per
client_id,submission_date,normalized_engine,partner_codeandsource. It runs alongsidesearch_clients_daily_v8; the sevenlegacy_columns carry a v8-comparable number from this table alone.Nothing consumes it yet, so nothing in production changes when this merges.
search.search_clients_daily_gleansap.countsevents or thelegacy_counters have activity for the keydate_partition_offset: -1, becauseserp_events_v2writes the previous day's partition — without it every SERP measure would publish as0, silentlyclient_idtest_sidescovers the four side combinations,test_legacy_labelsthe label shapes and partner-code attributionPost-merge
serp_events_v2's finishes. The floor is the rolling 775-day partition expiry, so the range is computed against the run dateRelated Tickets & Documents
Reviewer, please follow this checklist