[CT-2832] [Spike] Can the hook for latest model version unsuffixed view/clone leverage our clone macro/materialization?

[jtcohen6]

spike split out of #7442

We have documented/recommended some code for an opt-in post-hook, that creates an extra view pointing to the "latest" object: https://docs.getdbt.com/docs/collaborate/govern/model-versions#configuring-database-location-with-alias

Definition of done:

• Spike on whether we can clean up this code by leveraging the clone macro / materialization that we developed for v1.6

If we can get to cleaner code that's supported across DWHs, it's then just a UX question of whether this is enabled/disabled via yaml config (option 2) or post-hook (option 3)

[aranke]

Thanks to @mikealfare's work, we can simplify the macro in the documentation to the following:

{% macro create_latest_version_view() %}

    -- this hook will run only if the model is versioned, and only if it's the latest version
    -- otherwise, it's a no-op
    {% if model.get('version') and model.get('version') == model.get('latest_version') %}

        {% set target_relation = this.incorporate(path={"identifier": model['name']}) %}
        
        {% do log("Creating view " ~ target_relation ~ " pointing to " ~ this, info = true) if execute %}
        
        {{ return(get_replace_view_sql(target_relation, "select * from {{ this }}")) }}
        
    {% else %}
    
        -- no-op
        select 1 as id
    
    {% endif %}

{% endmacro %}

I think this resolves the spike @jtcohen6, what should the next steps here be?

[jtcohen6]

@aranke That's great news! I think the next step here is actually moving forward with:

• [CT-2468] [Feature] For versioned models, automatically create view/clone of latest version in unsuffixed database location #7442

By (roughly):

• executing that macro within the model run/build step
• iff it's a versioned model, and this is the latest version
• returning the appropriate information about the created/updated object to the cache

If that sounds right to you, I think we can close this spike and move forward with #7442 (schedule for the next sprint). Does that sound right to you?

[aranke]

Yup, that sounds right to me.
Closing this issue, and we can queue up #7442 for the next sprint.