-
Notifications
You must be signed in to change notification settings - Fork 38
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
[Regression] since 1.4.1, generate_alias_name overrides and refs to ephemeral models dont work anymore #284
Comments
Thanks for reporting this @rompetroll ! I was able to reproduce an error even without a customized Root causeI'm guessing this was related to some combination of #236 and dbt-labs/dbt-core#10290. Specifically, #236 was merged on Aug 8, 2024 and dbt-adapters 1.4.1 was released the next day on WorkaroundsThree main options in the meantime:
I'm guessing most would want to choose the 1st option rather than the other two. ReprexHere's the files and commands I used:
{{ config(
materialized="ephemeral",
alias="ignored_until_now",
)
}}
select 1 as id
{{ config(materialized="table") }}
select *
from {{ ref("my_ephemeral_model") }} Run this command:
Examine the compiled SQL code and see the mismatch:
with __dbt__cte__my_ephemeral_model as (
select 1 as id
) select *
from __dbt__cte__ignored_until_now |
@dbeatty10 In an effort to be very explicit, the expectation is that this: with __dbt__cte__my_ephemeral_model as (
select 1 as id
) select *
from __dbt__cte__ignored_until_now should be this: with __dbt__cte__ignored_until_now as (
select 1 as id
) select *
from __dbt__cte__ignored_until_now Correct? |
Yep, you got it @mikealfare 👍 The root cause is that #236 and dbt-labs/dbt-core#10290 are coupled and need to go together. The expectation is that when with __dbt__cte__ignored_until_now as (
select 1 as id
) select *
from __dbt__cte__ignored_until_now And we'd also expect that with __dbt__cte__my_ephemeral_model as (
select 1 as id
) select *
from __dbt__cte__my_ephemeral_model |
@rompetroll @dbeatty10 @mikealfare I've only done preliminary testing at this point, but it seems like this is resolved in v1.8.6, correct? |
My understanding is this is resolved. Closing the issue for now, feel free to reopen if you find otherwise @rompetroll |
Is this a regression?
Current Behavior
the CTE block for an ephemaral model is generated using the filename of the model as alias, but in places where the ephemaral model is referenced, the ref is replaced with a non-existent CTE alias, which seems to be constucted using the generate_alias_name macro.
Expected/Previous Behavior
CTE block alias and alias in ref resolution should match, to that queries become valid.
Steps To Reproduce
generate_alias_name
macro which modifies model namesRelevant log output
No response
Environment
Additional Context
No response
The text was updated successfully, but these errors were encountered: