Reputation: 1758
I am currently writing a custom dbt
materialization and I would like to know what is the best way / pattern to access the "current" model metadata from the materialization itself.
My model consists of two files:
sample_model.yaml
(with the model metadata)version: 2
models:
- name: sample_model
description: This is a test view to test a materialization
config:
schema: temp
materialized: custom_view
columns:
- name: custom_view_column_a
description: This is a test column A in a view
- name: custom_view_column_b
description: This is a test column B in a view
sample_model.sql
(with the "actual" model)SELECT
1 AS custom_view_column_a,
2 AS custom_view_column_b
In my custom materialization (custom_view
) I would like, for example, to access the columns defined in the model metadata (sample_model.yaml
). For the moment I could access them using the graph
variable, in this way:
{% set models = [] %}
{% for node in graph.nodes.values() | selectattr("resource_type", "equalto", "model") | selectattr("name", "equalto", this.identifier) %}
{% do models.append(node) %}
{% endfor %}
{% set model_metadata = models|first %}
{% set model_columns = model_metadata.get("columns") %}
This approach works quite well, however it "feels" a bit like (ab)using a sort of "global variable". Also the graph
could become very large considering it stores both the metadata and the SQL of all the models in the project!
Is there any other (local) object / variable I can access from the materialization that only stores the metadata of the model it's currently being materialized?
Upvotes: 1
Views: 1062
Reputation: 5805
{{ model }}
gives you the data from the graph for the current model node. I think it should work inside a materialization:
{% set model_metadata = model %}
You may want to gate it with execute
-- I'm not really sure if the first parsing pass templates the materialization code:
{% set model_metadata = model if execute else {} %}
Upvotes: 1