Dlaczego wymagane i opcjonalne jest usuwane w Buforach protokołów 3

Ostatnio używam gRPCz proto3i zauważyłem to requiredi optionalzostało usunięte w nowej składni.

Czy ktoś uprzejmie wyjaśni, dlaczego wymagane / opcjonalne są usuwane w proto3? Tego rodzaju ograniczenia wydają się konieczne, aby uczynić definicję solidną.

składnia proto2:

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

składnia proto3:

syntax = "proto3";
message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

Przydatność requiredbyła podstawą wielu debat i wojny z płomieniami. Po obu stronach istniały duże obozy. Jeden obóz lubił gwarantować, że wartość była obecna i był gotów żyć z jej ograniczeniami, ale drugi obóz czuł się requiredniebezpiecznie lub nieprzydatny, ponieważ nie można go bezpiecznie dodać ani usunąć.

Pozwól, że wyjaśnię ci więcej, dlaczego tak się dzieje required pola powinny być używane oszczędnie. Jeśli używasz już prototypu, nie możesz dodać wymaganego pola, ponieważ stare aplikacje nie będą go udostępniały, a aplikacje ogólnie nie radzą sobie z awarią. Możesz upewnić się, że wszystkie stare aplikacje są najpierw uaktualnione, ale może być łatwo popełnić błąd i nie pomaga, jeśli przechowujesz prototypy w dowolnym magazynie danych (nawet krótkotrwałym, takim jak memcached). Ten sam rodzaj sytuacji dotyczy usuwania wymaganego pola.

Wiele wymaganych pól było „oczywiście” wymaganych, dopóki… nie były. Powiedzmy, że masz idpole dla Getmetody. Jest to oczywiście wymagane. Poza tym później może być konieczna zmiana idz int na string lub z int32 na int64. To wymaga dodania nowego muchBetterIdpola, a teraz pozostało ci już stare idpole musi zostać określone, ale ostatecznie jest całkowicie ignorowane.

Po połączeniu tych dwóch problemów liczba korzystnych requiredpól staje się ograniczona, a obozy kłócą się o to, czy nadal ma ona wartość. Przeciwnicy requiredniekoniecznie byli przeciwni temu pomysłowi, ale jego obecnej formie. Niektórzy sugerowali opracowanie bardziej ekspresyjnej biblioteki sprawdzania poprawności, która mogłaby sprawdzić requiredwraz z czymś bardziej zaawansowanym, takim jakname.length > 10 , na przykład zapewniając lepszy model awarii.

Proto3 ogólnie wydaje się faworyzować prostotę, a requiredusuwanie jest prostsze. Ale może bardziej przekonujący, usuwającyrequired miało sens dla proto3 w połączeniu z innymi funkcjami, takimi jak usunięcie obecności pola dla prymitywów i usunięcie nadrzędnych wartości domyślnych.

Nie jestem deweloperem protobufów i nie jestem w żaden sposób autorytatywny w tym temacie, ale nadal mam nadzieję, że wyjaśnienie będzie przydatne.

Wyjaśnienie znajdziesz w tym numerze Github z protobufem :

Porzuciliśmy wymagane pola w proto3, ponieważ wymagane pola są ogólnie uważane za szkodliwe i naruszające semantykę zgodności protobuf. Cały pomysł użycia protobuf polega na tym, że pozwala on dodawać / usuwać pola z definicji protokołu, zachowując jednocześnie pełną kompatybilność do przodu / do tyłu z nowszymi / starszymi plikami binarnymi. Wymagane pola to jednak niszczą. Nigdy nie można bezpiecznie dodać wymaganego pola do definicji .proto, ani nie można bezpiecznie usunąć istniejącego wymaganego pola, ponieważ obie te czynności psują kompatybilność przewodów. Na przykład, jeśli dodasz wymagane pole do definicji .proto, pliki binarne zbudowane przy użyciu nowej definicji nie będą mogły analizować danych zserializowanych przy użyciu starej definicji, ponieważ wymagane pole nie występuje w starych danych. W złożonym systemie, w którym. definicje proto są szeroko udostępniane w wielu różnych komponentach systemu, dodawanie / usuwanie wymaganych pól może łatwo doprowadzić do awarii wielu części systemu. Wielokrotnie widzieliśmy problemy z produkcją i jest to prawie wszędzie zakazane w Google, aby każdy mógł dodawać / usuwać wymagane pola. Z tego powodu całkowicie usunęliśmy wymagane pola w proto3.

Po usunięciu „wymaganego”, „opcjonalne” jest po prostu zbędne, więc usunęliśmy również „opcjonalne”.