Versioning des schémas d’Espaces
Faire évoluer Marque, Travail, Personnel et futurs domaines sans casser les cerveaux existants.
Principe
Un Espace référence explicitement un schema_type et une schema_version.
Exemple :
brand@1
personal@1
work@2
Changement compatible
Ajouter une métadonnée facultative ou un type de relation peut être compatible.
Changement breaking
Renommer/supprimer un pilier, changer sa sémantique ou modifier les règles d’agrégation nécessite une nouvelle version.
Migration
L’utilisateur ne doit jamais perdre ses mémoires.
Une migration de schéma produit :
- mapping ancien → nouveau ;
- rapport d’ambiguïtés ;
- preview ;
- rollback si possible ;
- provenance de la migration.
Customisation
Les extensions personnalisées doivent préférer des sous-structures/metadata avant d’autoriser la modification libre des piliers racine.
Was this page helpful?