This example is taken from the jaffle_shop
example from dbt. Here is the views file structure:
views
βββ core
βΒ Β βββ customers.sql
βΒ Β βββ orders.sql.jinja
βββ staging
βΒ Β βββ customers.py
βΒ Β βββ orders.py
βΒ Β βββ payments.py
βββ tests
βββ orders_are_dated.sql
The first thing to do is create an .env
file, as so:
echo "
LEA_USERNAME=max
LEA_WAREHOUSE=duckdb
LEA_DUCKDB_PATH=jaffle_shop.db
" > .env
This example uses DuckDB as the data warehouse. With lea, the convention when using DuckDB is to use a separate .db
file per environment. For instance, in production, the file would be called jaffle_shop.db
. In development, the file would be called jaffle_shop_max.db
. The max
suffix is the username from the .env
file.
The following command creates the jaffle_shop_max.db
file and the necessary schemas:
lea prepare
Created schema analytics
Created schema core
Created schema staging
Now you can run the views:
lea run
There are a couple of cool things:
- The staging schema is populated using Python scripts. Each one outputs a pandas DataFrame, which lea automcatically writes to DuckDB.
- The
core.orders
table is created using a Jinja SQL script. lea will automatically run the script through Jinja, and then execute the resulting SQL.
You can then run some tests:
lea test
You can also generate documentation:
lea docs
This generates a docs
folder with the following structure:
docs
βββ README.md
βββ core
βΒ Β βββ README.md
βββ staging
βββ README.md
Now, if you were running in production and not in development mode, you would add a --production
flag to each command:
lea prepare --production
lea run --production
lea test --production
lea docs --production