🧠 Contexte
Dans dbt, les tests (unique
, not_null
, accepted_values
, etc.) peuvent être configurés avec un niveau de sévérité :
severity: error
→ stoppe le runseverity: warn
→ n’échoue pas le run, mais affiche une alerte
Quand ton projet dbt devient complexe (plusieurs domaines, plusieurs équipes, etc.), tu veux :
- Avoir un comportement par défaut pour tout le projet
- Pouvoir ajuster selon les dossiers ou modèles
- Et surcharger manuellement un test particulier
✅ La stratégie : hiérarchie avec override
L’ordre d’application est :
- Test local (dans
schema.yml
) → le plus prioritaire - Configuration par dossier (via
dbt_project.yml
) - Valeur par défaut globale (toujours
error
si rien n’est défini)
📁 Exemple complet
1. dbt_project.yml
– config globale et par dossier
name: my_project
version: 1.0
models:
my_project:
+severity: warn # ✅ valeur par défaut globale
marketing: # dossier models/marketing/
+severity: error
finance:
+severity: warn
2. models/marketing/schema.yml
– surcharge locale
version: 2
models:
- name: customers
columns:
- name: email
tests:
- not_null:
severity: warn # 🔁 surcharge locale
🔍 Ce que dbt va faire :
Cible | Configuration retenue | Justification |
---|---|---|
test not_null(email) dans marketing/customers | warn | car défini localement |
test sans config dans marketing | error | hérite du dossier marketing |
test sans config dans finance | warn | hérite du dossier finance |
test sans config ailleurs | warn | hérite du projet (+severity: warn ) |
✅ Résumé
En définissant les niveaux de sévérité (
severity
) à différents niveaux hiérarchiques, tu assures un comportement cohérent et contrôlé dans ton projet dbt.
Niveau | Priorité | Exemple d’emplacement |
---|---|---|
Individuel | 🔝 Haute | schema.yml du modèle |
Par dossier | Moyenne | dbt_project.yml > models > dossier |
Global projet | Basse | dbt_project.yml > models |
Défaut dbt | Plus basse | severity: error |