Presencia de campos en Protocol Buffers: distinguir entre asignar cero y dejar un campo sin cambios

Qué es

La nota sobre presencia de campos de Protocol Buffers distingue entre presencia implícita y presencia explícita. Con presencia implícita, los campos escalares que tienen su valor por defecto no conservan un estado explícito de «asignado», y el comportamiento de fusión (merge) documentado omite los valores por defecto. La presencia explícita, en cambio, permite representar un campo asignado deliberadamente a su valor por defecto. Esto importa cuando un mensaje se utiliza también como solicitud de actualización parcial. Protocol Buffers field presence

Por qué importa

Un agente puede interpretar el cero como «sin actualización» e impedir sin querer que un cliente ponga un contador a cero o desactive un ajuste. Otra implementación, por su parte, puede sobrescribir un valor existente con el valor por defecto solo porque el campo se omitió. Conviene definir la intención de la actualización de forma independiente del valor escalar en sí.

Cómo aplicarlo

• Para cada campo de la actualización, describe qué significa que esté ausente, presente con un valor distinto del valor por defecto y presente con el valor por defecto. Incluye de forma explícita la semántica de borrado o restablecimiento.
• Elige una representación en el esquema que exprese esos estados, como la presencia explícita donde esté disponible o una máscara de actualización documentada. No supongas que el getter generado, por sí solo, indica si se proporcionó un valor.
• Sigue la solicitud a través de todos los intermediarios y operaciones de fusión. Comprueba que un participante más antiguo o una conversión de serialización no descarte la información de presencia que exige el contrato de actualización.
• Propón fixtures que partan de un valor almacenado distinto del valor por defecto: omitir el campo, asignar otro valor distinto del valor por defecto y asignar explícitamente el valor por defecto. Verifica que los resultados sean distintos allí donde el contrato lo exija.
• Repite los fixtures a través del transporte público real y de la API generada para el lenguaje. Documenta la sintaxis o edición y las versiones del runtime que intervienen en ese recorrido.

Trampas

La compatibilidad a nivel de wire no garantiza que se conserve la intención de actualización de la aplicación. Los campos repetidos (repeated), los mapas y los campos de tipo mensaje tienen su propio comportamiento de presencia y no conviene aplicarles de forma mecánica las reglas de los escalares. Además, una máscara de actualización debe validarse contra el esquema real de la solicitud. Este artículo propone un contrato de actualización parcial y un plan de verificación; no afirma que se haya ejecutado ninguna prueba de interoperabilidad entre versiones mixtas.