Referencias: https://github.com/TheThingsNetwork/lorawan-stack/issues/2047
Los valores devueltos por NS para enumeraciones dentro del campo mac_settings
son inconsistentes. Algunos para algunos NS devuelven valores sin formato y para otros se devuelve una representación de cadena.
mac_settings.rx1_delay.value
// request
{
"end_device":{
"mac_settings":{
"rx1_delay":{
"value":5 // or 'RX_DELAY_5'
}
}
},
"field_mask":{
"paths":[
"mac_settings.rx1_delay.value",
]
}
}
// response
{
...
"mac_settings":{
"rx1_delay":{
"value":5
},
}
}
// Note, regardless of what you send as the value for mac_settings.rx1_delay.value you always get the raw enum value.
mac_settings.ping_slot_periodicity.value
// request
{
"end_device":{
"mac_settings":{
"ping_slot_periodicity":{
"value": 1 // or 'PING_EVERY_2S'
}
}
},
"field_mask":{
"paths":[
"mac_settings.ping_slot_periodicity.value"
]
}
}
// response
{
"mac_settings":{
"ping_slot_periodicity":{
"value":"PING_EVERY_2S"
}
}
}
// Again, regardless of what you send you always get the string representation of the value.
Valores inconsistentes para campos de enumeración mac_settings
Todos los valores deben devolverse en el mismo formato (sin formato/cadena)
v3.7.0-rc2
Supongo que primero tenemos que acordar el formato. Luego es cuestión de ajustar https://github.com/TheThingsNetwork/lorawan-stack/blob/master/api/lorawan.proto y https://github.com/TheThingsNetwork/lorawan-stack/blob/master/pkg /ttnpb/lorawan.go
Sí, pero necesito información de @rvolosatovs @johanstokking @htdvisser
¿Qué información se requiere de nosotros ( @rvolosatovs @johanstokking @htdvisser)? ¿A este problema le falta una etiqueta discussion
?
FTR, creo que depende de los campos de los que estemos hablando, pero para cosas MAC específicas de LoRaWAN, creo que deberíamos usar solo el número, ya que se alinea con la especificación (la periodicidad de la ranura de ping de PING_EVERY_2S
no es definido en la especificación, sin embargo, el de 1
lo es)
Desafortunadamente, esto no es algo que podamos cambiar, ya que violaría nuestro compromiso de compatibilidad de API, por lo que definitivamente no es algo para marzo.
Actualmente, existen múltiples formas de representar una enumeración. Por ejemplo, MACVersion
se puede representar como "MAC_V1_0_2"
, 3
(ambos compatibles con jsonpb) o como "1.0.2"
(con el stringer de TTN, no compatible). En el pasado, cometimos el error de usar el tercero ( "1.0.2"
) al renderizar JSON. No deberíamos haber hecho eso, pero ya no podemos cambiar eso sin romper nuestra API.
Para ser lo más compatibles posible, aceptamos todos los formularios en los mensajes de solicitud, pero lo que devolvemos ya no se puede cambiar fácilmente.
En el futuro (con la API de goproto v2) quizás podríamos agregar soporte para una extensión en el encabezado Accept
, similar a cómo lo hace Github. Esta extensión podría usarse para decirle al servidor cómo se deben representar las enumeraciones (y, por ejemplo, los campos cero).
cerrado ya que no arreglaremos esto
No creo que debamos descartar esto inmediatamente como una solución. Mantengámoslo en la cartera de pedidos y veamos si podemos arreglarlo en el futuro.
Genial para V4
Comentario más útil
Genial para V4