Hi team, We upgraded to elementary 0.15.1 and dbt 1.8. We are using alias as shown and realized that after upgrade some of the elementary models are not getting updated at all. Last generated day is showing May 29th while our project runs every 2 hrs. Could you please help to investigate what can be probable reason of models not getting updated?

@Preeti Taneja Elementary 0.15 updates models only when required. It uses hashes (AFAIK built-in DBT model hashes) to detect if a model was changed. So if you don't change anything in a project - Elementary will skip some (or even all) DBT artifacts

Thanks Denis, Is there a way we can force building these? We are using generated_at date for creating further models and if the date is not updated then it can cause issues for us.

Elementary models are incremental, you can force full refresh. According to Elementary's chat-bot (available on their site):

To enable a full refresh for Elementary incremental models, you need to configure the

elementary_full_refresh

variable in your

dbt_project.yml

file. Here's an example of how to set it to `true`:

```vars:

elementary_full_refresh: true```

To run a full refresh on your Elementary models, you can use the following

dbt

command:

Copy code

dbt run --select elementary --vars '{"elementary_full_refresh": "true"}'

This ensures that all Elementary incremental models are fully refreshed, including historical runs and test results.

Got it, Denis. Thanks!

> We are using generated_at date for creating further models and if the date is not updated then it can cause issues for us. Could you clarify why you use that column? Can you use

dbt_invocations

instead?

We are using dbt_invocations too but the metrics are calculated for each day and hence generated_day plays important role as well.

Well, what kind of metrics do you calculate? It's not correct to rely on Elementary internals as behavior may change in the future once again, and refreshing elementary every time can require more and more resources as a project grows. dbt_invocation, on the contrary, can be considered as a contract (despite being said explicitly): 1 row per invocation, you can join it with test results table for example.