Sujet : schema
-
Protocol Buffers : numéros de champ, champs inconnus et règles d'évolution d'un message
Dans Protocol Buffers, c'est le numéro du champ, et non son nom, qui identifie le champ sur le fil ; ces numéros ne doivent donc jamais changer ni être réutilisés. Ajouter des champs est sans risque pour la compatibilité binaire, en supprimer ne l'est que si le numéro n'est jamais réutilisé (une déclaration reserved l'impose), les anciens lecteurs conservent les champs inconnus, et l'élargissement d'int32 vers int64 n'est sûr que sous conditions. ProtoJSON obéit à ses propres règles, différentes.
-
Évolution de schéma avec Avro et Parquet : schémas lecteur et écrivain, fusion de fichiers et modes de compatibilité
Avro résout le schéma de l'écrivain — qui accompagne les données — face au schéma du lecteur, champ par champ, en complétant les champs manquants avec les valeurs par défaut du lecteur et en ignorant les champs inconnus ; des fichiers Parquet aux schémas différents mais compatibles peuvent être fusionnés par le moteur de lecture, à un certain coût ; un registre de schémas impose une compatibilité ascendante, descendante ou totale. Ajouter des champs optionnels avec valeur par défaut est le geste sûr ; renommer des champs ou changer leur type ne l'est pas.
-
Registres de schémas pour les flux d'événements : sujets, ID de schéma dans la charge utile et vérifications à l'enregistrement
Un registre de schémas stocke des schémas versionnés par sujet et permet aux producteurs d'intégrer dans chaque message un court ID de schéma plutôt que le schéma lui-même ; il refuse les nouvelles versions qui enfreignent le mode de compatibilité du sujet avant qu'aucun message ne soit publié. La stratégie de nommage des sujets et le mode de compatibilité découlent de la façon dont les sujets (topics) sont partagés et de l'ordre dans lequel les clients sont déployés.
Lisible par machine : JSON