Add if execute check within _is_relation

[jtcohen6]

Context: dbt-labs/dbt-core#7024 (comment)

Describe the feature

More consistent behavior in _is_relation at parse time, to avoid raising confusing errors.

It's quite common to call get_relation or load_cached_relation, and then pass it into a macro that validates the input via _is_relation. That validation can't happen at parse time — because dbt hasn't yet connected to the database and doesn't yet have access to the adapter/relation cache, those methods return None instead of a Relation object.

I'd propose updating the logic of _is_relation to check if execute before raising an exception. Something like:

{% macro _is_relation(obj, macro) %}
    {%- if execute and not (obj is mapping and obj.get('metadata', {}).get('type', '').endswith('Relation')) -%}
        {%- do exceptions.raise_compiler_error("Macro " ~ macro ~ " expected a Relation but received the value: " ~ obj) -%}
    {%- endif -%}
{% endmacro %}

We should probably do the same for _is_ephemeral, since refs don't actually resolve at parse time either. (They will return a Relation object, but it's a pointer to this model, not the actually referenced model.)

Describe alternatives you've considered

• Adding these if execute no-op checks within the macros that require introspection, sequentially before the call to _is_relation. This is already the case for some macros (e.g. equality), but not others (e.g. get_filtered_columns_in_relation.
• Actually moving this macro into dbt-core: [CT-705] Review dbt_utils "helper" methods: _is_relation + _is_ephemeral dbt-core#5316

Who will this benefit?

Anyone using introspective dbt_utils macros who don't yet understand the finer nuances of the adapter cache + parsing vs. compilation vs. runtime (internal docs)

Are you interested in contributing this feature?

sure!

[vinit2107]

Linking #817
I think it's the same issue.

[github-actions]

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please comment on the issue or else it will be closed in 7 days.

[github-actions]

Although we are closing this issue as stale, it's not gone forever. Issues can be reopened if there is renewed community interest. Just add a comment to notify the maintainers.