web-dev-qa-db-fra.com

Pourquoi requis et facultatif est supprimé dans les tampons de protocole 3

J'utilise récemment gRPC avec proto3 et j'ai remarqué que required et optional ont été supprimés dans une nouvelle syntaxe.

Quelqu'un voudrait-il bien expliquer pourquoi les éléments obligatoires/facultatifs sont supprimés dans proto3? Ce type de contraintes semble simplement nécessaire pour rendre la définition robuste.

syntaxe proto2:

message SearchRequest {
  required string query = 1;
  optional int32 page_number = 2;
  optional int32 result_per_page = 3;
}

syntaxe proto3:

syntax = "proto3";
message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}
protocol-buffersgrpcproto3
172
yjzhang

L’utilité de required a été au cœur de nombreux débats et guerres enflammées. De grands camps ont existé des deux côtés. Un camp aimait garantir qu’une valeur était présente et était disposé à vivre avec ses limites mais l’autre camp se sentait required dangereux ou inutile car il ne pouvait être ni ajouté ni supprimé en toute sécurité.

Laissez-moi expliquer davantage le raisonnement pour lequel les champs required devraient être utilisés avec parcimonie. Si vous utilisez déjà un proto, vous ne pouvez pas ajouter de champ obligatoire, car les anciennes applications ne le fourniront pas et les applications en général ne gèrent pas correctement l'échec. Vous pouvez vous assurer que toutes les anciennes applications sont mises à niveau en premier, mais il peut être facile de faire une erreur et cela n'aide pas si vous stockez les protos dans any datastore (même de courte durée, comme memcached). Le même type de situation s'applique lors de la suppression d'un champ obligatoire.

De nombreux champs obligatoires étaient "évidemment" obligatoires jusqu'à ... ils ne l'étaient pas. Supposons que vous ayez un champ id pour une méthode Get. C'est évidemment requis. Sauf que, plus tard, vous devrez peut-être changer le id de int en chaîne, ou int32 en int64. Cela nécessite l’ajout d’un nouveau champ muchBetterId, et il ne vous reste plus que l’ancien champ id que doit être spécifié, mais il est finalement complètement ignoré.

Lorsque ces deux problèmes sont combinés, le nombre de champs bénéfiques required devient limité et les camps se disputent pour savoir s'il a encore une valeur. Les adversaires de required n'étaient pas nécessairement contre l'idée, mais sa forme actuelle. Certains ont suggéré de développer une bibliothèque de validation plus expressive capable de vérifier required ainsi que quelque chose de plus avancé comme name.length > 10, tout en veillant à disposer d'un meilleur modèle de défaillance.

Dans l’ensemble, Proto3 semble privilégier la simplicité, et le retrait de required est plus simple. Mais peut-être plus convaincant, la suppression de required était logique pour proto3 lorsqu'elle était combinée à d'autres fonctionnalités, telles que la suppression de la présence de champs pour les primitives et la suppression des valeurs par défaut.

Je ne suis pas un développeur de protobuf et je ne fais absolument pas autorité sur le sujet, mais j'espère quand même que l'explication est utile.

315
Eric Anderson

Vous pouvez trouver l'explication dans ceci numéro de protobuf Github :

Nous avons abandonné les champs obligatoires dans proto3 car ceux-ci sont généralement considérés comme nuisibles et violent la sémantique de compatibilité de protobuf. L'utilisation de protobuf a pour principe de vous permettre d'ajouter/de supprimer des champs de votre définition de protocole, tout en restant totalement compatible avec les versions antérieures/antérieures. Les champs obligatoires divisent cela cependant. Vous ne pouvez jamais ajouter en toute sécurité un champ obligatoire à une définition .proto, ni supprimer en toute sécurité un champ obligatoire existant, car ces deux actions brisent la compatibilité filaire. Par exemple, si vous ajoutez un champ obligatoire à une définition .proto, les fichiers binaires construits avec la nouvelle définition ne pourront pas analyser les données sérialisées à l'aide de l'ancienne définition, car le champ requis n'est pas présent dans les anciennes données. Dans un système complexe où les définitions .proto sont largement partagées entre de nombreux composants différents du système, l'ajout/la suppression de champs obligatoires peut facilement détruire plusieurs parties du système. Nous avons constaté à maintes reprises des problèmes de production, et il est pratiquement interdit partout dans Google d’ajouter ou de supprimer des champs obligatoires. Pour cette raison, nous avons complètement supprimé les champs obligatoires dans proto3.

Après la suppression de "obligatoire", "facultatif" est simplement redondant, nous avons donc supprimé également "facultatif".

25
maiyang