https://linen.dev logo
Join Slack
Powered by
<@U088WCP3B4P> I don't want to run the elementary ...
# ask-elementary-ai
l
@kapa.ai I don't want to run the elementary models in my project when I try a simple dbt run, I want just the hooks running (cz they actually run the elementary models too right?)
k
A message from kapa.ai
You can absolutely do that: keep the Elementary hooks, but avoid running the Elementary models on normal 
dbt run
/ 
dbt build
. ### Key points from the docs - Elementary only needs its models run once (install) and on minor version upgrades to apply schema changes. Day‑to‑day runs can safely skip them.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq)] - The on-run-start / on-run-end hooks still run and will continue to upload run/test results etc. even if the Elementary models are excluded or disabled.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – hooks vs models](https://elementary-community.slack.com/archives/C02CTC89LAX/p1705024991103189)] You have two main options: --- ### Option 1 – Exclude Elementary models via CLI (simplest) For your regular runs:
Copy code
bash dbt run --exclude elementary # or dbt build --exclude elementary
This skips all 
package:elementary
models, while hooks still execute and populate the existing Elementary tables.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – exclude elementary](https://elementary-community.slack.com/archives/C02CTC89LAX/p1680788180937509)] When you upgrade Elementary and need to rebuild its tables:
Copy code
bash dbt run --select elementary
--- ### Option 2 – Disable Elementary models by default in 
dbt_project.yml
Configure Elementary models to be disabled by default and only enable them when you explicitly choose to:
Copy code
yml models:   elementary:     +schema: elementary     edr:       +enabled: "{{ var('enable_elementary_models', false) }}"
Then: - Normal runs (no models, hooks still run):
Copy code
bash   dbt run
- When you do want to (re)build Elementary models (e.g., after upgrade):
Copy code
bash   dbt run --select elementary --vars '{"enable_elementary_models": true}'
[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – disable models via var](https://elementary-community.slack.com/archives/C02CTC89LAX/p1678322775440989)] --- So: use 
--exclude elementary
or the `+enabled`/var pattern to stop Elementary models from running; the hooks will still execute and keep your observability data up to date.
l
Is there a way to set these to run just once and no more? @kapa.ai
k
A message from kapa.ai
Yes. Elementary is designed so that its models only need to be run: 1. Once on initial installation (to create the tables), and 2. On minor version upgrades (e.g. 
0.15.x → 0.16.x
) when schema changes are introduced.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – when to run models](https://elementary-community.slack.com/archives/C02CTC89LAX/p1715108071844039)] Outside of those cases, you can configure things so they never run again automatically and only the hooks populate the tables. ### How to do it 1. Disable Elementary models by default in `dbt_project.yml`:
Copy code
yml models:   elementary:     +schema: elementary     edr:       +enabled: "{{ var('enable_elementary_models', false) }}"
This makes Elementary models not run in normal 
dbt run
/ 
dbt build
.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – disable via var](https://elementary-community.slack.com/archives/C02CTC89LAX/p1678322775440989)] 2. Run them only when you choose (install or upgrade):
Copy code
bash dbt run --select elementary --vars '{"enable_elementary_models": true}'
Do this once per environment on install, and again only when you upgrade Elementary and need schema changes applied.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq)] The on-run-end hooks continue to run and populate the existing Elementary tables even if the models themselves are disabled or excluded.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – hooks vs models](https://elementary-community.slack.com/archives/C02CTC89LAX/p1715108071844039)]
l
@kapa.ai enable_elementary_models is this native from dbt?
k
A message from kapa.ai
No, 
enable_elementary_models
is not a native dbt setting or reserved keyword. It’s just an example of a user-defined var name that you can choose yourself and reference in 
dbt_project.yml
, e.g.:
Copy code
yml models:   elementary:     +schema: elementary     edr:       +enabled: "{{ var('enable_elementary_models', false) }}"
In this pattern, 
enable_elementary_models
is a normal dbt 
var
you define and control (via 
vars:
in 
dbt_project.yml
or 
--vars
on the CLI) to toggle whether Elementary models are enabled. [[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – disable via var](https://elementary-community.slack.com/archives/C02CTC89LAX/p1678322775440989)]
l
@kapa.ai But if I put this in a template: Yes. Elementary is designed so that its models only need to be run: 1. Once on initial installation (to create the tables), and 2. On minor version upgrades (e.g. 
0.15.x → 0.16.x
) when schema changes are introduced.[OSS FAQ; Slack – when to run models] When he will know when to run these models? If the variable is always false?
k
A message from kapa.ai
The idea is: - You set the var to 
false
by default so that normal runs never build Elementary models. - You (or your team / pipeline) manually flip it to 
true
only when you decide to rebuild Elementary models (install or minor upgrade). Elementary itself does not auto‑toggle this flag; you control it. A common pattern from the docs and Slack answers is:
Copy code
yml # dbt_project.yml models:   elementary:     +schema: elementary     edr:       +enabled: "{{ var('enable_elementary_models', false) }}"
Normal jobs:
Copy code
bash dbt run              # var defaults to false → models not built # or dbt build
When you want to rebuild (first install, or minor version upgrade):
Copy code
bash dbt run --select elementary --vars '{"enable_elementary_models": true}'
This is a deliberate, manual action you wire into your deployment/upgrade process (e.g., a “post‑upgrade” job that runs 
dbt deps
+ 
dbt run --select elementary --vars ...
). [[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – disable via var](https://elementary-community.slack.com/archives/C02CTC89LAX/p1678322775440989); [Slack – when to run models](https://elementary-community.slack.com/archives/C02CTC89LAX/p1715108071844039)]
l
But for first-timers this variable needs to be true then right? Shit, that's a problem quite serious cause I'm making a dbt template and I don't want to keep running these models after the first time they are intialized I'm trying to use that variable vars: disable_dbt_artifacts_autoupload: true But It is kinda useless if the model is still running @kapa.ai
k
A message from kapa.ai
You’re right on both points: 1. First‑timers do need the models to run once to create the Elementary tables. 2. You don’t want them to keep running automatically afterwards in your template. You can achieve both without confusing first‑time users by combining: - A one‑time “setup” command that they run explicitly. - A project config that keeps models off by default in day‑to‑day runs. - Optionally, disablement vars so hooks can be turned off too if needed. --- ### 1. Template config: keep models off by default In your 
dbt_project.yml
, configure Elementary like this:
Copy code
yml models:   elementary:     +schema: elementary     edr:       +enabled: "{{ var('enable_elementary_models', false) }}"
This follows the pattern documented in the FAQ: models are disabled by default and only run when 
enable_elementary_models
is explicitly set to 
true
.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq)] Result: - 
dbt run
/ 
dbt build
(no special vars) → Elementary models do not run. - Hooks still run and upload results, assuming the tables exist.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq)] --- ### 2. First‑time (and upgrade) instructions in the template In your template’s README, add a clear “initialization” step:
Copy code
bash # One-time setup (and on minor Elementary upgrades) dbt run --select elementary --vars '{"enable_elementary_models": true}'
This is exactly what Elementary recommends: run the models once on install and on minor version upgrades.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq)] So: - Yes, for the first run, 
enable_elementary_models
must be 
true
. - But you don’t hard‑code it to 
true
in the project; you only pass it via 
--vars
in that one command. Day‑to‑day, users just run 
dbt run
/ 
dbt build
with no vars, and models stay off. --- ### 3. About 
disable_dbt_artifacts_autoupload
disable_dbt_artifacts_autoupload
and the other vars control what the hooks upload, not whether the models themselves run. [[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – disable hooks](https://elementary-community.slack.com/archives/C02CTC89LAX/p1677157737267389)] For example, to fully disable uploads in some env:
Copy code
yml vars:   disable_run_results: true   disable_tests_results: true   disable_dbt_artifacts_autoupload: true   disable_dbt_invocation_autoupload: true
But these **do not stop dbt from trying to build the models**; that’s what the `+enabled`/`var('enable_elementary_models', false)` pattern is for. --- ### TL;DR for your template - Put this in `dbt_project.yml`:
Copy code
yml   models:     elementary:       +schema: elementary       edr:         +enabled: "{{ var('enable_elementary_models', false) }}"
- Document one explicit “setup” command for first‑timers (and upgrades):
Copy code
bash   dbt run --select elementary --vars '{"enable_elementary_models": true}'
This way: - First‑timers have a clear, single step to initialize. - Normal project runs never keep rebuilding Elementary models.
l
@kapa.ai Can I declare in dbt_project.yml a kinda of deafult paramter for every build? For example for every build always exclude this package
k
A message from kapa.ai
Short answer from the Elementary docs/slack: there is no documented way (in these sources) to set a global default 
--exclude
in 
dbt_project.yml
 so that every 
dbt build
automatically excludes a package. What is documented are these options: 1. Disable the Elementary package by config (per target/env) Example patterns:
Copy code
yml    models:      elementary:        +schema: "elementary"        +enabled: "{{ target.name in ['prod','analytics'] }}"
This means in all other targets, Elementary models won’t run at all, regardless of CLI flags.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Disable per env](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684138562765719)] Or using a var:
Copy code
yml    models:      elementary:        +schema: elementary        edr:          +enabled: "{{ var('enable_elementary_models', false) }}"
Then you only enable them explicitly with 
--vars '{"enable_elementary_models": true}'
when needed.[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Disable via var](https://elementary-community.slack.com/archives/C02CTC89LAX/p1678322775440989)] 2. Use 
--exclude elementary
or 
--exclude package:elementary
in your commands This is repeatedly suggested for skipping Elementary models/tests in specific runs, including CI and micro‑batches, e.g.: ```bash dbt run --exclude elementary dbt build --exclude elementary ```[[OSS FAQ](https://docs.elementary-data.com/oss/general/faq); [Slack – exclude elementary](https://elementary-community.slack.com/archives/C02CTC89LAX/p1693288324394649); [Micro-batch example](https://elementary-community.slack.com/archives/C02CTC89LAX/p1747229110843109)] Given the provided sources, they do not show a way to encode a “default 
--exclude
for every build” directly in `dbt_project.yml`; instead, they rely on: - 
+enabled
conditions (per env/var), or - Explicit CLI 
--exclude
usage. If you need it to always be excluded in a certain environment, the recommended pattern here is the 
+enabled
condition rather than a global default CLI flag.
35 Views
Open in Slack
PreviousNext
Powered by