Présence des champs en Protocol Buffers : distinguer la mise à zéro explicite de l'absence de modification d'un champ

Ce que c'est

La note de Protocol Buffers sur la présence des champs distingue la présence implicite et la présence explicite. Avec la présence implicite, les champs scalaires à valeur par défaut ne portent pas le même état explicite « défini », et les valeurs par défaut sont omises par le comportement de fusion documenté. La présence explicite permet de représenter un champ délibérément défini à sa valeur par défaut. Cela importe lorsqu'un message fait aussi office de requête de mise à jour partielle. Présence des champs en Protocol Buffers

Pourquoi c'est important

Un agent peut interpréter zéro comme « aucune mise à jour » et empêcher accidentellement un client de remettre à zéro un compteur ou de désactiver un réglage. Une autre implémentation peut écraser une valeur existante par une valeur par défaut simplement parce que le champ a été omis. Définir l'intention de mise à jour séparément de la valeur scalaire elle-même.

Comment l'appliquer

• Pour chaque champ de mise à jour, écrire ce que signifient absent, présent avec une valeur non par défaut, et présent avec la valeur par défaut. Inclure explicitement une sémantique d'effacement ou de réinitialisation.
• Choisir une représentation de schéma qui exprime ces états, telle que la présence explicite là où elle est prise en charge, ou un masque de mise à jour documenté. Ne pas supposer que le getter généré révèle à lui seul si une valeur a été fournie.
• Suivre la requête à travers chaque intermédiaire et chaque opération de fusion. Vérifier qu'un participant plus ancien ou une conversion de sérialisation n'élimine pas des informations de présence requises par le contrat de mise à jour.
• Proposer des cas de test partant d'une valeur stockée non par défaut : omettre le champ, définir une autre valeur non par défaut, et définir explicitement la valeur par défaut. Vérifier des résultats distincts là où le contrat l'exige.
• Rejouer ces cas de test à travers le transport public réel et l'API du langage générée. Documenter la syntaxe ou l'édition ainsi que les versions d'exécution impliquées dans ce chemin.

Pièges

La compatibilité au niveau du fil (wire) ne garantit pas la préservation de l'intention de mise à jour applicative. Les champs répétés, les maps et les champs de message ont leur propre comportement de présence et ne devraient pas hériter mécaniquement des règles des scalaires. Un masque de mise à jour a lui aussi besoin d'être validé par rapport au schéma réel de la requête. Cet article propose un contrat de mise à jour partielle et un plan de vérification ; il ne revendique aucun test d'interopérabilité entre versions mixtes réellement exécuté.