Defining your model properties
Aside from configurations, you can also assign properties to your models to further customise their functionalities.
Part of the “Mastering dbt” series. Access to the full Study Guide. Let’s connect on LinkedIn!
Notes from this documentation.
Model properties are declared in a dedicated .yml file placed within your models directory. You can have multiple files of this type, allowing you to apply different properties to each subdirectory.
These files can be named whatever you want. We will refer to this file as “properties.yml” in this post. In the actual project, it’s a good idea to add an underscore before the name so it’s always sorted at the top of the folder.
Finally, I will not cover the time-spine property here because it’s not a topic in the exam. All other properties will be covered, although some will be seen top line here for a further deep-dive in future Checkpoints.
If the difference between properties and configs still isn’t clear, check this blog post.
Available properties
name (required):
The model name needs to match the name of the model file, including case sensitivity.
description:
A description to be added to the project’s documentation. They can include markdown, Jinja functions, docs blocks, and even images (using assets).
latest_version:
Used in conjunction with the “versions” property to define which version is the latest one.
If defined, the ref function will always refer to the version assigned to this property. Also, you can use the “version:” method to select the latest version: dbt list --select "version:latest"
versions: (this property will be covered in more detail in future Checkpoints)
This is a dbt feature that allows you to define different versions for your models. It takes the following parameters:
v: the identifier for the version which can be numeric or a string. These identifiers will be sorted (numerically or alphabetically) to define the oldest to newest versions.
You can use the “version:” method to select the desired version: dbt list --select "version:1"
defined_in (optional): the name of the model file where the version lives. If not defined, dbt looks for a “<model_name>_v<v>” file.
alias: when building the different versions into the warehouse, dbt will use the “<model_name>_v<v>” template by default. This parameter allows you to override it.
For the defined_in and alias parameters, dbt recommends using them only when necessary.
include/exclude (optional): a list of columns to include in the given version. It can be set to “all” or “*”. “Exclude” can only be used if all columns were included.
deprecation_date:
Sets a date for when the model is deprecated. After this date has passed, dbt will issue a warning message if you try to run the model. This property works well with versions and other model governance features, which will be covered later in the guide.
constraints:
Additional validation steps for the data. If these validations fail, the model won’t be built, and an error message will be issued. These will be covered in more detail in future Checkpoints.
data_tests:
This property enables you to ensure certain assertions are always true in your data, such as that a column has no null or duplicate values. We will cover these generic tests and custom tests in future Checkpoints.
quote:
Applicable to columns. Defines whether column names should be wrapped in quotes. Particularly useful for Snowflake and for when reserved words are used (like “rank”), for example. Default is false.
