fix(dimensional): dispatch regexp_like in dim_course_run so it builds on DuckDB - #2658
Merged
Merged
Conversation
… on DuckDB
dim_course_run.sql:191 called Trino's regexp_like() directly instead of the
cross-database dispatch macro, so the model could not build on the dev_local
DuckDB target:
Runtime Error in model dim_course_run
Catalog Error: Scalar Function with name regexp_like does not exist!
The model errored, its 16 tests skipped, and everything downstream skipped with
it. Since dim_course_run is the spine of the dimensional layer, that blocked
local validation of the whole mart/reporting migration epic (#2072), not just
this model.
macros/cross_db_functions.sql:193 already dispatches regexp_like (default ->
Trino native, duckdb__ -> regexp_matches, starrocks__ -> regexp); the call site
was just missing its {{ }}. This was the only remaining raw regexp_like under
models/ -- verified with:
grep -rn 'regexp_like(' src/ol_dbt/models/ | grep -v '{{'
(The two raw calls in cross_db_functions.sql itself are inside
default__from_iso8601_timestamp, the Trino-specific implementation, where a raw
Trino call is correct.)
No production behavior change: there is no trino__regexp_like override, so Trino
resolves to default__regexp_like, which emits regexp_like(expr, pattern)
verbatim -- character-identical to the SQL compiled today.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
🔎 ol-dbt impact — column-level blast radius✅ No column-level downstream impact detected for the changed models. Posted by |
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The focused change correctly uses the established macro and preserves existing Trino semantics.
Pull request overview
Fixes dim_course_run to use the existing cross-database regex macro, enabling DuckDB builds without changing Trino behavior.
Changes:
- Dispatches
regexp_likethrough the database-specific macro.
File summaries
| File | Description |
|---|---|
src/ol_dbt/models/dimensional/dim_course_run.sql |
Uses cross-database regex dispatch for course ID parsing. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
rachellougee
approved these changes
Sep 10, 2026
quazi-h
added a commit
that referenced
this pull request
Sep 16, 2026
…nd the stale-registration evidence CORRECTION to d6806b0. I wrote that `+dim_course_run` fails because dim_course_run.sql:191 calls `regexp_like` raw. That is false on current main: PR #2658 dispatched it and merged 2026-09-11, and the dispatched form is present in this branch's merge-base too. I read the raw version out of the main checkout, which is 35 commits behind origin/main (153a76e vs bb2bcfc) — I verified the claim against a stale tree, which is the same class of mistake as testing a different command from the one I shipped. The real blockers are three ANCESTORS carrying Trino-only JSON SQL, per tk-three-trino-only-json-models-block-building-dim--59c2db and confirmed against origin/main: stg__edxorg__api__course.sql:20 and stg__mitxpro__app__postgres__cms_certificatepage.sql:17 (`json_query(... with array wrapper)` wrapped in json_parse and cast to array), and int__mitxpro__coursesfaculty.sql:9 (`cast(json_parse(...) as array (json))`). The cascade is what makes it total: those error, int__edxorg__mitx_courseruns and int__mitxpro__courses skip, and since the dims `union all` every platform one broken branch skips the whole dim. Measured on #2686: PASS=48 ERROR=3 SKIP=5 TOTAL=56. Also noted #2658 explicitly so nobody hunts for the regexp_like that is already gone. Added the gate the #2686 run argued for, which is sharper than what I had: both comparison sides must appear with status: success in run_results.json before any number is measured -- not "the run finished", not "no errors scrolled past". Added the evidence for step 1's stability rule, which is the best argument in the file for it: on #2686 a staging layer registered hours earlier read 4,513 rows where a fresh registration read 4,996, and that 483-row gap was published and retracted. It was convincing because the stale side was internally consistent — the _pre model and the built dim both came from it, so the diff was a clean 0/0. A stale registration does not look stale, it looks like agreement. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What are the relevant tickets?
Unblocks epic #2072 — not a sub-issue of it, but a prerequisite:
dim_course_runis the spine of the dimensional layer, so this gates local validation of every mart/reporting migration under that epic.Description (What does it do?)
dim_course_run.sql:191called Trino'sregexp_like()raw instead of the dispatch macro that already exists atcross_db_functions.sql:193, so the model died on thedev_localDuckDB target withCatalog Error: Scalar Function with name regexp_like does not exist!— taking its 16 tests and everything downstream down with it. The call site was just missing its{{ }}:No production change: there is no
trino__regexp_likeoverride, so Trino resolves todefault__regexp_like, which emitsregexp_like(expr, pattern)verbatim.How can this be tested?
On
mainthis errors immediately; on this branch the model builds (12,503 rows) and all 17 tests run, with every test ondim_course_run's own columns passing.pre-commitandol-dbt validate(0 errors) are clean.Additional Context
You will see 4 inbound FK relationship tests fail (
tfact_enrollment,dim_product, and two bridges). They are pre-existing mixed-graph noise, not this change:courserun_pkismd5(platform || '-' || courserun_readable_id)and does not involvecourse_readable_id, the only column this diff touches. Confirmed empirically too — all 45 oftfact_enrollment's orphanedcourserun_fkvalues exist in the productiondim_course_run, so the locally rebuilt table just has a narrower population than the production upstreams it is being compared against.🤖 Generated with Claude Code