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

Use sql instead of compiled_code within the default get_limit_sql macro #372

Merged
merged 5 commits into from
Dec 19, 2024

Conversation

dbeatty10
Copy link
Contributor

@dbeatty10 dbeatty10 commented Dec 5, 2024

resolves #370

Problem

#249 (comment)

@VersusFacit and @mikealfare Looks like this line should be using the function parameter {{ sql }}. It works with {{ compiled_code }} I assume because of the context being set in the get_show_sql macro, but that's likely hiding a future bug.

I could be wrong, but ran into this when providing a custom version of get_show_sql in my project.

Solution

Just swap out sql for compiled_code.

Checklist

  • I have read the contributing guide and understand what's expected of me
  • I have run this code in development, and it appears to resolve the stated issue
  • Tests are not required/relevant for this PR
  • This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc.)

@cla-bot cla-bot bot added the cla:yes label Dec 5, 2024
@dbeatty10 dbeatty10 changed the title Use sql instead of compiled_code within the default `get_limit_sq… Use sql instead of compiled_code within the default get_limit_sql macro Dec 5, 2024
@dbeatty10 dbeatty10 marked this pull request as ready for review December 5, 2024 21:18
@dbeatty10 dbeatty10 requested a review from a team as a code owner December 5, 2024 21:18
@VersusFacit
Copy link
Contributor

Interesting code change 🤔

Before we merge something like this, can we get some downstream CI builds from concrete adapters that show this is correct? Adapters itself doesn't have the functional tests to give us confidence

@dbeatty10
Copy link
Contributor Author

@VersusFacit Assuming something like this will do the trick?

@dbeatty10
Copy link
Contributor Author

@VersusFacit Assuming something like this will do the trick?

Assuming so, opened this draft PR to run tests against this branch: dbt-labs/dbt-postgres#178

Does something similar need to be done on adapters other than dbt-postgres? Or is this sufficient?

@dbeatty10
Copy link
Contributor Author

@VersusFacit all checks on dbt-postgres passed on dbt-labs/dbt-postgres#178 -- see below for screenshot.

Does something similar need to be done on adapters other than dbt-postgres? Or is this sufficient?

image

@amychen1776
Copy link
Contributor

@dbeatty10 are you able to test this out on other adapters too? That would give me more confidence

@dbeatty10
Copy link
Contributor Author

dbeatty10 commented Dec 11, 2024

@amychen1776 no prob here ya go:

Process

  1. Open each of these links:
  2. Open the "Run workflow" drop down
  3. Fill out the following info (placing dbt-adapters-372 (free-form descriptive label) & dbeatty/fix-370 (the branch name of this PR) in the right spots):
    image
  4. Click the "Run workflow" button to submit
  5. Click on the workflow run once it is dispatched to see the details
    image
  6. Copy the URL of the workflow run into this PR
    e.g., https://github.com/dbt-labs/dbt-snowflake/actions/runs/12279964774

Note

https://github.com/dbt-labs/dbt-postgres/actions/workflows/integration.yml was not found for dbt-postgres, so that will needs some follow-up to standardize. But this is covered by dbt-labs/dbt-postgres#178 for now. See dbt-labs/dbt-postgres#181 for proposed fix.

Copy link
Contributor

@VersusFacit VersusFacit left a comment

Choose a reason for hiding this comment

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

all CI passed. Thanks for your patience @dbeatty10 . I stayed on late to squeeze this in for the last pre-holiday release after we left you hanging ❤️

@VersusFacit VersusFacit merged commit d7165c1 into main Dec 19, 2024
32 checks passed
@VersusFacit VersusFacit deleted the dbeatty/fix-370 branch December 19, 2024 03:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug] compiled_code instead of sql within default__get_limit_sql macro
3 participants