Comments (7)
For the initial request:
As of now, when specified at the column level, it displays accordingly. However, if declared at the model level constraint, it doesn't appear at either level. I wouldn't oppose consistently displaying it at the column level. What's essential to me is ensuring visibility of the primary key, especially when handling multiple primary key fields in BigQuery, which currently doesn't function when declared in the column level constraint.
from dbt-docs.
Thanks for reaching out @salimmoulouel !
It sounds like you have two asks (please correct me if I'm misunderstanding!):
- Display the model-level constraints in the documentation generated by dbt
- Ability to define multiple primary key constraints at the column level
Assuming that complete documentation is your main ask here, I'm going to transfer this issue to dbt-docs for further consideration.
1. Display the model-level constraints in the documentation generated by dbt
You want the documentation website (dbt docs generate && dbt docs serve
) to display a "PK" label for each of those columns, possibly like this?
2. Multiple primary key constraints at the column level
I don't remember off the top of my head, but I think there are technical reasons for us not supporting this. Feel free to open up a separate issue for this one if you'd like, but I'm guessing we'd close as "won't do".
Reprex
models/my_model.sql
select 1 as pk_1, 2 as pk_2
models/_models.yml
models:
- name: my_model
config:
materialized: table
contract:
enforced: true
# model-level constraints
constraints:
- type: primary_key
columns: [pk_1, pk_2]
# column-level constraints
columns:
- name: pk_1
data_type: int
constraints:
- type: not_null
- name: pk_2
data_type: int
constraints:
- type: not_null
Build and launch the dbt project docs:
dbt docs generate && dbt docs serve
from dbt-docs.
Currently, the docs have five main sections:
- Details
- Description
- Columns (which contains column-level constraints)
- Depends on
- Code
And none of those sections includes model-level constraints like these:
Does that sound right? If so, would adding a new section for model-level constraints solve this for you?
from dbt-docs.
Here's the files + commands I'm using to see how this is behaving currently:
Reprex
models/dual.sql
{{ config(materialized="ephemeral") }}
select 'X' as dummy
models/my_other_model.sql
select
3 as other_pk_1,
4 as other_pk_2
from {{ ref("dual") }}
models/my_model.sql
select
1 as pk_1,
2 as pk_2,
3 as fk_1,
4 as fk_2,
5 as check_1,
6 as check_2
from {{ ref("dual") }}
models/_models.yaml
models:
- name: my_other_model
config:
materialized: table
contract:
enforced: true
# model-level
constraints:
- type: primary_key
columns: [other_pk_1, other_pk_2]
- type: unique
columns: [other_pk_1, other_pk_2]
# column-level
columns:
- name: other_pk_1
data_type: int
- name: other_pk_2
data_type: int
- name: my_model
config:
materialized: table
contract:
enforced: true
# model-level
constraints:
- type: primary_key
columns: [pk_1, pk_2]
- type: unique
columns: [pk_1, pk_2]
- type: foreign_key
columns: [fk_1, fk_2]
expression: "YOUR_SCHEMA_HERE.my_other_model (other_pk_1, other_pk_2)"
- type: check
columns: [check_1, check_2]
expression: "check_1 != check_2"
name: human_friendly_name
# column-level
columns:
- name: pk_1
data_type: int
- name: pk_2
data_type: int
- name: fk_1
data_type: int
- name: fk_2
data_type: int
- name: check_1
data_type: int
- name: check_2
data_type: int
dbt build --full-refresh
dbt docs generate && dbt docs serve
from dbt-docs.
sorry for the late answer, i Think yes, that would be perfect, thank you.
from dbt-docs.
Do you believe this is a challenge we can resolve in the coming days? This matter pertains to a proof of concept (POC) that, if successful, will guide several teams within our company toward adopting dbt.
from dbt-docs.
Summary
We'd be open to adding model-level constraints to the generated documentation website.
I've labeled this as refinement
for us to determine how exactly the user experience would look for this and to determine acceptance criteria.
Timeline
This isn't a time-sensitive priority for us. So no, this is not something that would be available on the timeline you mentioned.
Workaround
However, we do have other capabilities that would allow you to add your own free-form content to the documentation website.
The description field can contain Markdown which provides some flexibility for how you want to format things.
Example
models:
- name: my_other_model
config:
materialized: table
contract:
enforced: true
description: >
### Model-level constraints
- primary_key: [`other_pk_1`, `other_pk_2`]
- unique: [`other_pk_1`, `other_pk_2`]
# model-level
constraints:
- type: primary_key
columns: [other_pk_1, other_pk_2]
- type: unique
columns: [other_pk_1, other_pk_2]
dbt docs generate && dbt docs serve
Screenshot
from dbt-docs.
Related Issues (20)
- [CT-3089] [CT-3065] [Feature] DBT docs allow to view grants for each model HOT 1
- [CT-3077] Testing issue opening from another workflow
- [CT-3237] Display compiled metric code in docs HOT 2
- [CT-3238] Display the metric definition/configuration in dbt docs HOT 2
- [CT-3244] [CT-3241] [Feature] Docs increase size of Description field and reduce the column field size HOT 2
- [CT-3248] [CT-3247] [Feature] <dbt docs - support for nested path> HOT 2
- [CT-3265] The docs generated for exposures should display owner HOT 3
- [CT-3331] Exposures aren't displaying any properties (dbt > 1.6.0) HOT 3
- [CT-3371] Include unit tests in dbt docs HOT 3
- [CT-3427] [CT-3415] [Feature] LaTeX rendering in DBT docs HOT 1
- [CT-3498] [CT-3490] DBT Docs: Add Meta As A Filter Checkbox HOT 2
- [CT-3523] [regression] missing details for exposures in dbt docs page
- [CT-3530] Presence of `saved_queries` breaks lineage viz
- [CT-3533] dbt docs generate doesn't hide package's documentation HOT 3
- Docs only showing tags in details section of source objects HOT 3
- Macro naming conventions HOT 4
- Testing issue opening from another workflow
- [Feature] Add information on the column type to the documenation of source tables HOT 1
- Docs site does not support unit tests HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dbt-docs.