@rex it looks like in recent versions after upgrading to the new DBT API the raw sql string is stil getting parsed from dagster even if the DBT manifest is set to only include a non compiled (parsed only) manifest. Is this true? Or is this a misconception/edge case which works (as my mini DBT project so far is not using any macros)

I’m not sure what your question is here, could you clarify? Here’s the default implementation for retrieving a description for a dbt asset: https://github.com/dagster-io/dagster/blob/92a4c919d926a94c2d3063930387264c4c6d2f5[…]python_modules/libraries/dagster-dbt/dagster_dbt/asset_utils.py

def default_description_fn(dbt_resource_props: Mapping[str, Any], display_raw_sql: bool = True):
    code_block = textwrap.indent(
        dbt_resource_props.get("raw_sql") or dbt_resource_props.get("raw_code", ""), "    "
    )
    description_sections = [
        dbt_resource_props["description"]
        or f"dbt {dbt_resource_props['resource_type']} {dbt_resource_props['name']}",
    ]
    if display_raw_sql:
        description_sections.append(f"#### Raw SQL:\n```\n{code_block}\n```")
    return "\n\n".join(filter(None, description_sections))

The raw SQL is displayed by default. If you want to change this behavior, then you can implement your own

get_description

for `DagsterDbtTranslator`: https://docs.dagster.io/integrations/dbt/reference#customizing-descriptions

No, I do want to get the sql. But in the past only the compiled manifest provided this (when using macos).

The compiled manifest has

compiled_code

. This is referencing the

raw_code

. They are not the same. In the code i posted above:

dbt_resource_props.get("raw_code", "")

ok thx understood