Contrôle de schéma

Contrôle de schéma (t_check_schema) confronte chaque ligne aux types que vous déclarez, convertit ce qui s'y prête, puis trie : les lignes conformes d'un côté, les autres de l'autre, avec la raison du rejet.

Entrées	Sorties
in : le flux de données	valid : les lignes conformes, aux types déclarés
after : signal d'ordonnancement	invalid : les lignes rejetées + la colonne du motif

Trier, pas arrêter

La brick Assertion fait échouer le pipeline quand une règle est violée. C'est ce qu'on veut d'un contrat interne — mais pas de données qui arrivent du dehors.

Un lot de dix mille factures dont trente portent un montant illisible ne doit pas être perdu tout entier. Ici, les trente sont mises de côté avec leur motif, et les neuf mille neuf cent soixante-dix continuent.

Paramètres

Le panneau liste les colonnes reçues de l'amont : on choisit pour chacune le type attendu, sans retaper son nom. Tout déclarer les reprend toutes avec le type que l'amont annonce — le geste de départ, à affiner ensuite.

Paramètre	Défaut	Description
schema	[]	Les colonnes à contrôler : column, type, required, max_length.
convert	true	Convertir les colonnes déclarées aux types déclarés.
allow_unknown_columns	true	Laisser passer les colonnes que le schéma ne déclare pas.
error_column	_schema_error	Nom de la colonne de motif ajoutée à la sortie rejetée.

Les types disponibles sont ceux du studio : Texte, Entier, Nombre à virgule, Décimal exact, Booléen, Date, Date / Heure.

Convertir et juger sont le même geste

« Est-ce du bon type ? » n'a pas de réponse utile sur des données du dehors, où tout arrive en texte : un "42" de CSV est un entier pour qui le lit et une chaîne pour qui regarde le type. La question qui compte est donc : cette valeur se convertit-elle ?

Une seule opération y répond, et c'est la même qui produit la sortie. Ce qui a été validé est exactement ce qui est émis.

La sortie est un contrat verrouillé

Puisque les colonnes déclarées portent réellement les types déclarés, le studio verrouille le schéma de sortie tout seul : le cadenas est posé par la brick, pas à cocher. Il ne dit rien de plus que ce qu'elle fait déjà.

Sans conversion, pas de contrat

convert décoché, les valeurs traversent telles quelles et seule leur lisibilité est contrôlée. Le verrou se relâche alors automatiquement : déclarer un Entier sur une colonne restée textuelle ferait refuser à l'émission une table que la brick vient de laisser passer.

Ce que la lecture sait accepter

Type	Accepte
Entier	42, "42", " 7 " — mais pas "3.5" : arrondir inventerait une donnée
Nombre à virgule	10.5, "1234.56", et "1234,56" (virgule française)
Booléen	true/false, 1/0, oui/non, yes/no, vrai/faux
Date, Date / Heure	tout ce que le moteur sait dater
Texte	toute valeur simple — un tableau ou un objet est refusé

La virgule décimale, oui ; la devinette, non

"1234,56" est lu comme un nombre : c'est ce que produit tout export français, et le refuser rejetterait des montants parfaitement valides.

"1,234.56" et "1,2,3" restent ambigus — ils sont rejetés, pas devinés.

La longueur — la faute qui ne se voit qu'à l'écriture

Un libellé de trente-deux caractères passe tous les contrôles de type. Il fait échouer l'insertion dans un varchar(30), bien plus loin, sur un message du pilote qui nomme la table et pas la ligne.

max_length l'écarte ici, avec la valeur sous les yeux et le compte exact :

« libelle » : 27 caractères pour 10 autorisé(s) — « beaucoup trop long pour dix »

Le champ n'apparaît que sur les colonnes de type Texte : plafonner un entier ou une date ne veut rien dire.

Trois précisions

La longueur se mesure sur la valeur convertie — c'est elle qui partira en base. Une case vide n'a pas de longueur et ne se voit rien reprocher. Et une valeur illisible est déjà rejetée pour son type : lui reprocher sa longueur en plus ferait deux motifs pour une seule faute.

Un plafond à 0 ou vide ne plafonne rien : un champ à moitié saisi ne doit pas rejeter tout un lot.

L'obligatoire : la présence ET les valeurs

Une case vide n'est pas une faute de type : elle est vide. Sans cette distinction, déclarer un type reviendrait à déclarer une obligation que vous n'avez pas demandée.

required gouverne les deux questions que pose une colonne :

	required coché	required décoché
La colonne manque	toutes les lignes sont écartées	rien n'est rejeté, elle sort vide
Une case est vide	la ligne est écartée	la ligne passe
Une valeur est du mauvais type	la ligne est écartée	la ligne est écartée

Le motif d'une case vide le dit avec ses mots à lui (« montant » est obligatoire et vide), pas avec un message de conversion qui ferait chercher au mauvais endroit.

Une colonne absente est quand même déclarée

Même non obligatoire, une colonne du schéma qui ne serait pas dans les données est posée, vide et au bon type dans la sortie conforme. Le schéma l'annonce ; l'aval n'a pas à découvrir son absence. L'exécution le signale en journal : une colonne déclarée qui n'arrive jamais est souvent un renommage en amont qu'on n'a pas suivi.

Les colonnes hors schéma — le dynamique

Le schéma déclare ce qui compte, pas tout ce qui passe : une colonne surnuméraire traverse sans un mot, et le schéma de sortie porte la clé DYNAMIC, qui dit « et tout le reste, quel qu'il soit ». Sans elle, chaque colonne non déclarée serait signalée comme un écart, à chaque exécution, sur un flux pourtant correct.

Décocher Laisser passer les colonnes hors schéma ferme la table : elles sont retirées de la sortie, et le schéma ne porte plus que les colonnes déclarées. Utile pour un export contractuel vers un tiers, où une colonne de trop est une fuite.

Retirées, pas rejetées

Une colonne surnuméraire est un fait de table, pas une faute de ligne : condamner dix mille lignes parce qu'il en arrive une de trop serait hors de proportion.

Le motif de rejet

La sortie Non conforme porte une colonne de plus, qui dit pourquoi. Une ligne peut cumuler plusieurs motifs, séparés par ; :

« quantite » : « douze » n'est pas du type Entier; « actif » : « peut-être » n'est pas du type Booléen

La brick ne s'arrête pas à la première colonne fautive : corriger un jeu de données une colonne à la fois demanderait autant d'exécutions qu'il y a de fautes.

Une colonne obligatoire absente de la table n'est pas un défaut de ligne mais de table : toutes les lignes partent en rejet, avec le motif colonne « x » absente. La sortie conforme sort vide, et la panne est évidente tout de suite plutôt qu'en aval, sur une erreur de clé.

Cas d'usage

Une chaîne de traitement de factures OCRisées :

1. l'OCR produit du texte pour toutes les colonnes ;
2. Contrôle de schéma vérifie que montant est bien un nombre, date_facture une date, numero un entier ;
3. la sortie Conforme part vers la base, déjà aux bons types — la conversion a eu lieu au passage ;
4. la sortie Non conforme part dans un fichier de reprise — chaque ligne porte déjà la raison, et personne n'a à retrier à la main.