Skip to main content
View as Markdown

Validation

Sovrium valide les données à deux niveaux : au moment de la configuration (le schéma est décodé avec Effect Schema au démarrage de l'application, capturant les définitions invalides) et à l'exécution (les enregistrements sont vérifiés par rapport aux règles de champ, aux contraintes et aux permissions à chaque écriture). Cette page résume la surface de validation des tables.

Validation au niveau du champ

De nombreux types de champs portent une validation intégrée dérivée de leurs propriétés :

Règle S'applique à Effet
required Tous les champs La valeur doit être présente sur chaque enregistrement.
unique Tous les champs Deux enregistrements ne peuvent partager la valeur.
min / max integer, decimal, currency, percentage La valeur doit tomber dans la plage inclusive.
precision decimal (1–10), currency/percentage (0–10) Restreint les décimales.
currency (ISO 4217) currency Doit être un code à trois lettres valide.
maxLength rich-text Plafonne la longueur de caractères.
maxSelections multi-select Plafonne les choix ; ne peut dépasser le nombre d'options.
options single-select, multi-select, status Les valeurs doivent provenir de la liste d'options déclarée.
validation de format email, url Doit correspondre à la RFC 5322 / une URL absolue valide.
targetLanguage ai-translate Doit être un code ISO 639-1 (éventuellement suffixé par une région).
categories / tags ai-categorize / ai-tag Minimum 2 entrées, sans doublons.

Validation au niveau de la table (au moment de la configuration)

Lorsque le schéma est décodé, Sovrium applique des règles structurelles et rejette les configurations invalides avec des erreurs descriptives :

  • Les noms et identifiants de champs doivent être uniques au sein d'une table.
  • Les noms de champs et de tables doivent correspondre à ^[a-z][a-z0-9_]* (après assainissement) et rester dans la limite de 63 caractères.
  • Les noms d'index et les noms de contraintes doivent être uniques au sein de la table et correspondre au motif d'identifiant.
  • Les champs de clé primaire doivent référencer de véritables champs.
  • Les index, permissions, vues, webhooks sont vérifiés afin que leurs références de champ nomment de véritables champs de la table.
  • Les champs count / rollup / lookup doivent référencer un champ relationship existant dans la même table.
  • Les champs formula sont validés pour des références de champs correctes.
  • Les noms de webhooks doivent être uniques, et les sélecteurs de champs payload doivent nommer de véritables champs (l'id implicite est toujours valide).

Contraintes CHECK

Utilisez les contraintes CHECK pour les règles inter-champs et conditionnelles que la validation au niveau du champ ne peut exprimer :

constraints:
  - { name: chk_end_after_start, check: 'end_date > start_date' }
  - { name: chk_active_members_have_email, check: '(is_active = false) OR (email IS NOT NULL)' }

Unicité et intégrité

  • Unicité mono-champ : field.unique: true ou un unique: [{ fields: [x] }] de premier niveau.
  • Unicité composite : unique: [{ fields: [a, b] }] de premier niveau (devient un index unique) ou un index unique.
  • Unicité partielle : un index unique avec une clause where (par ex. slug unique uniquement parmi les lignes non supprimées).
  • Intégrité relationnelle : les champs relationship créent des clés étrangères avec des actions onDelete/onUpdate ; les références composites utilisent foreignKeys.