Repository navigation
Fix: do not apply model_defaults statements to external models - #6189
simen-strand wants to merge 2 commits into
Conversation
External models inherited the model_defaults pre_statements, post_statements and on_virtual_update, but are built without the project's macros and never execute statements. When a default statement called a project macro and its text changed, the plan rendered the external model's statements to compare them and failed with "Macro '<name>' does not exist". Stop external models from inheriting these defaults, as is already done for the default gateway. This changes the fingerprint of external models in projects that use default statements; the empty migration bumps the state schema version so cached models are rebuilt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Simen Strand <simen.strand@netcheck.de>
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Simen Strand <simen.strand@netcheck.de>
Description
External models inherit the
pre_statements,post_statementsandon_virtual_updatefrommodel_defaults, but they never run them, and they're built without the project's macros. If a default statement calls a project macro and you edit it, the plan tries to render the external models' copies and fails:This PR stops external models from inheriting those three defaults, the same way they already skip the default
gateway. Statements set explicitly on an external model are kept. The docs now say the defaults don't apply to external models.Upgrade impact
Projects whose
model_defaultsdefine statements will see a one-off change on their first plan after upgrading:SELECT *from an undeclared source), the defaultexternal: fullauto-categorization makes the change breaking, and that external model's downstream models are backfilled. A forward-only plan, orexternal: semi, avoids that.Projects without default statements are unaffected.
Alternatives considered
Test Plan
@tag_query('v1'), change it tov2, plan again. It fails onmainwith the error above and passes here.mainand planning with this branch. The results match the impact described above, and a forward-only plan needs no backfill.Checklist
make styleand fixed any issuesmake fast-test)git commit -s) per the DCOSummary by CodeRabbit
Bug Fixes
Documentation