Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix!: render audits at runtime #3667

Merged
merged 1 commit into from
Jan 20, 2025
Merged

Conversation

georgesittas
Copy link
Contributor

@georgesittas georgesittas commented Jan 20, 2025

The motivation behind this PR is that, given this model:

MODEL (
  name test_model,
  kind INCREMENTAL_BY_UNIQUE_KEY (
    unique_key (a, d)
  ),
  audits (
    unique_combination_of_columns(
      columns = (a, d),
      condition = d between @start_date and @end_date
    )
  ),
);

SELECT
  1 AS a,
  CAST('2025-01-20' AS DATE) AS d

The audit condition renders as follows at runtime today:

"d" BETWEEN CAST('1970-01-01' AS DATE) AND CAST('1970-01-01' AS DATE)

The reason this happens is that the model meta is rendered at load time and we store the properties to the corresponding pydantic fields, e.g. audits, even though start_date is a variable that changes depending on the runtime stage.

Approach is similar to e104491.

@georgesittas georgesittas requested a review from a team January 20, 2025 20:03
@georgesittas georgesittas force-pushed the jo/render_audits_at_runtime branch from bd541d4 to 8f6df7f Compare January 20, 2025 20:04
Copy link
Collaborator

@erindru erindru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Would this change the fingerprint of existing models that had audits?

@georgesittas
Copy link
Contributor Author

georgesittas commented Jan 20, 2025

Would this change the fingerprint of existing models that had audits?

It does, but I didn't notice it during testing because the old, rendered version of audits had been cached locally and so there was no metadata diff!

EDIT: after discussing offline, I realized that we can't really heal this with a migration because the snapshot payload would previously contain the following entry for audits:

"audits":[["unique_combination_of_columns",{"columns":"(a, d)","condition":"d BETWEEN CAST(\'1970-01-01\' AS DATE) AND CAST(\'1970-01-01\' AS DATE)"}]]

So, there’s no information about using variables whatsoever. The snapshot will still have the rendered date in it, but the local model will now have the @start_date and @end_date variables and we’ll inevitably get a metadata diff.

@georgesittas georgesittas merged commit 7519f43 into main Jan 20, 2025
21 checks passed
@georgesittas georgesittas deleted the jo/render_audits_at_runtime branch January 20, 2025 21:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants