lightdash dbt run -s my_model
.
schema.yml
file.
For example, if you just created a new orders.sql
model and you run lightdash dbt run -s orders
, an orders.yml
file will be generated in your dbt project with all columns documented, like this:
lightdash preview
command for this step.
Once you’ve generated your Tables and YAML files in dbt, you can test them out in a Lightdash preview environment.
Developer previews are temporary Lightdash projects where you can safely experiment with your metrics, dimensions and charts without affecting your production project.
So, let’s spin up a developer preview and check out our changes. In your terminal, run the commands:
Orders
and each column will appear as a dimension:
dbt_khindson.my_model_names
), then you’ll need to pass the production target in your lightdash deploy
command. Something like: lightdash deploy --target prod
.lightdash deploy
from the CLI after initial project setup. It’s better to have an automated process like Github actions that push code changes in your dbt projet into Lightdash.staging
tables, I’m looking at you 👀). So, we’ve made it possible for you to configure which Tables you want to appear in Lightdash.
To get to your table settings:
prod
, so we’ve configured our Tables using that tag.
labels
config)
joins
config)
.sql
file per model (these are the files where all of our models’ business logic sits).yml
file per model (these are the files where all of your Tables’ configuration sits)schema.yml
details for all of their models in a single YAML file at the directory level, and that’s totally fine - it will still work with Lightdash.
But, like we said just above, if you’re trying to decide how to setup your dbt project, we’d recommend having one YAML file per model.
lightdash dbt run
command supports dbt model selection syntax to generate YAML files for a group of models. This means you can use tags or other model selection syntax to specify which models you want to generate dimensions for in your dbt project.