protocol-buffers - google - protobuf python
¿Cómo diseñar para un futuro valor de enumeración adicional en búferes de protocolo? (1)
Una de las características atractivas de los búferes de protocolo es que le permite extender las definiciones de mensajes sin romper el código que usa la definición anterior. En el caso de una enumeración según la documentación :
un campo con un tipo de enumeración solo puede tener una de un conjunto específico de constantes como su valor (si intenta proporcionar un valor diferente, el analizador lo tratará como un campo desconocido)
por lo tanto, si extiende la enumeración y usa el nuevo valor, entonces un campo con ese tipo en el código anterior no estará definido o tendrá su valor predeterminado, si lo hay.
¿Cuál es una buena estrategia para lidiar con esto, sabiendo que en el futuro la enumeración puede tener valores adicionales agregados?
Una forma que me viene a la mente es definir un miembro "indefinido" de la enumeración y hacer que sea el predeterminado, entonces el código antiguo sabrá que se le ha enviado algo que no puede interpretar. ¿Es sensato, hay mejores maneras de lidiar con esta situación?
Sí, el mejor enfoque es hacer que el primer valor de la enumeración sea algo como UNKNOWN = 0 . Luego, los programas antiguos que leen un protobuf con un valor de enumeración que no reconocen lo verán como UNKNOWN y esperamos que puedan manejarlo de manera razonable, por ejemplo, saltándose ese elemento.
Si desea hacer esto, también querrá que la enumeración sea optional no es required .
required , generalmente significa "Prefiero que el programa aborte antes que manejar algo que no entiende".
Tenga en cuenta que debe ser el primer valor declarado en la fuente de proto ; solo el valor cero no lo convierte en el valor predeterminado.