added macro for wh selection

[javiCalvo]

resolves #103 Macro for warehouse selection

Description

The change is minimal to call a macro that gets the actual / default warehouse for the model and returns the same but can be overriden for more complex logics (ie. select a different warehouse depending on the environment). Test are missing as I don't know how to start with them but the change is working.

Checklist

• I have signed the CLA
• I have run this code in development and it appears to resolve the stated issue
• [] This PR includes tests, or tests are not required/relevant for this PR
• I have updated the CHANGELOG.md and added information about my change to the "dbt-snowflake next" section.

[jtcohen6]

@javiCalvo Looping back after a long delay — let us know if this is something you'd still be interested in contributing. My interest here is around making the _use_warehouse behavior a bit more consistent with how other method-macro handoffs happen for dbt adapters.

[jtcohen6]

Rather than a macro that returns the name of the warehouse, and then templating + executing use warehouse ... right from within the Python context, I think it would be better to have the Jinja macro template out the actual SQL we want to run (use warehouse {{ warehouse }}) and execute that SQL, via statement or run_query

That way, self.execute_macro accomplishes the full intended functionality, and we don't need the implicit call to self.execute (a.k.a. adapter.execute).

The macro could be named use_warehouse or use_snowflake_warehouse. To accomplish your intended functionality, you could still override that macro, adding complex conditional rules to determine the warehouse name, as long as the macro still templates out use warehouse ... and executes that SQL.

[javiCalvo]

Thanks for the comment, I'm not sure if I'm getting the idea 100%. You suggest to implement a macro like this:

{% macro use_warehouse(warehouse) -%}
  {% call statement('use_warehouse') -%}
    use warehouse {{ warehouse }}
  {%- endcall %}
{%- endmacro %}

And then the _use_warehouse method will be like:

    def _use_warehouse(self, warehouse: str):
        """Use the given warehouse. Quotes are never applied."""
        kwargs = {
            'warehouse': warehouse
        }
        self.execute_macro(
            SNOWFLAKE_USE_WAREHOUSE_MACRO_NAME,
            kwargs=kwargs
        )

If I'm getting this right then the macro override will have to make the call statement also? for example:

{% macro use_warehouse(warehouse) -%}

{% set warehouse = warehouse | replace('_X_', '_' + {'stg': 'D', 'tst': 'Q', 'prd': 'P'}[target.name] + '_') %}

{% call statement('use_warehouse') -%}
    use warehouse {{ warehouse }}
{%- endcall %}

{%- endmacro %}

Because I think the previous implementation is simpler in terms of macro override, but maybe is more inconsistent in the adapter implementation I don't know.

[jtcohen6]

@javiCalvo Sorry for the delayed response on my end!

Fair point. It is in closer keeping with how other adapter methods/macros work in dbt today, but I also appreciate wanting a narrower macro that just templates the desired SQL.

Another way we could factor this:

{% macro get_use_warehouse_sql(warehouse) -%}
    use warehouse {{ warehouse }}
{%- endmacro %}

    def _use_warehouse(self, warehouse: str):
        """Use the given warehouse. Quotes are never applied."""
        kwargs = {
            'warehouse': warehouse
        }
        use_warehouse_sql = self.execute_macro(
            SNOWFLAKE_USE_WAREHOUSE_MACRO_NAME,
            kwargs=kwargs
        )
        self.execute(use_warehouse_sql)

Then your override can be just this (returning a string, no call, much easier to test):

{% macro get_use_warehouse_sql(warehouse) -%}
   {% set warehouse = warehouse | replace('_X_', '_' + {'stg': 'D', 'tst': 'Q', 'prd': 'P'}[target.name] + '_') %}
    use warehouse {{ warehouse }}
{%- endmacro %}

[McKnight-42]

@javiCalvo this is looking very good, might need you to rerun pre-commit commands locally tried to fix a conflict we were having between main and guess pre-commit didn't like that (so sorry about that).

[McKnight-42]

@javiCalvo going to close this in favor of #503 to get your change ready for merger thank you for all your work.