प्रोटोकॉल बफ़र्स 3 में क्यों आवश्यक और वैकल्पिक हटा दिया गया है


214

मैं हाल ही में उपयोग कर रहा हूँ gRPCके साथ proto3है, और मुझे लगता है कि ध्यान दिया है requiredऔर optionalनई वाक्य रचना में हटा दिया गया है।

क्या कोई कृपया बताएगा कि प्रोटो 3 में आवश्यक / वैकल्पिक को क्यों हटाया गया है? परिभाषा को मजबूत बनाने के लिए इस तरह की अड़चनें जरूरी हैं।

वाक्यविन्यास प्रोटो 2:

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

वाक्यविन्यास प्रोटो 3:

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

जवाबों:


390

requiredएक बहस और लौ युद्ध के दिल में इसकी उपयोगिता रही है। दोनों तरफ बड़े-बड़े शिविर मौजूद हैं। एक शिविर को यह पसंद आया कि एक मूल्य की गारंटी मौजूद थी और वह अपनी सीमाओं के साथ जीने के लिए तैयार था लेकिन दूसरे शिविर को requiredखतरनाक या अपवित्र महसूस हुआ क्योंकि इसे सुरक्षित रूप से नहीं जोड़ा जा सकता है और न ही हटाया जा सकता है।

मुझे इस बात के बारे में और अधिक समझाना requiredचाहिए कि खेतों को संयम से क्यों इस्तेमाल किया जाना चाहिए। यदि आप पहले से ही एक प्रोटो का उपयोग कर रहे हैं, तो आप एक आवश्यक फ़ील्ड नहीं जोड़ सकते क्योंकि पुराने एप्लिकेशन को वह फ़ील्ड प्रदान नहीं किया जाएगा और सामान्य रूप से एप्लिकेशन विफलता को अच्छी तरह से संभाल नहीं पाते हैं। आप यह सुनिश्चित कर सकते हैं कि सभी पुराने एप्लिकेशन पहले अपग्रेड किए गए हैं, लेकिन एक गलती करना आसान हो सकता है और यह मदद नहीं करता है यदि आप किसी भी डेटास्टोर (यहां तक ​​कि अल्पकालिक की तरह,) में प्रोटोज स्टोर कर रहे हैं । एक आवश्यक फ़ील्ड निकालते समय एक ही तरह की स्थिति लागू होती है।

कई आवश्यक फ़ील्ड "स्पष्ट रूप से" आवश्यक थे जब तक ... वे नहीं थे। मान लीजिए कि आपके पास idएक Getविधि के लिए एक फ़ील्ड है । यह स्पष्ट रूप से आवश्यक है। को छोड़कर, बाद में आपको idइंट से स्ट्रिंग या इंट 32 से इंट 64 में बदलने की आवश्यकता हो सकती है । एक नए muchBetterIdफ़ील्ड को जोड़ने की आवश्यकता है , और अब आपको पुराने idफ़ील्ड के साथ छोड़ दिया गया है जिसे निर्दिष्ट किया जाना चाहिए, लेकिन अंततः पूरी तरह से अनदेखा कर दिया जाता है।

जब उन दो समस्याओं को जोड़ दिया जाता है, तो लाभकारी requiredक्षेत्रों की संख्या सीमित हो जाती है और शिविर यह तर्क देते हैं कि क्या अभी भी इसका मूल्य है। requiredविचार के विरोधी जरूरी नहीं थे, लेकिन इसका वर्तमान स्वरूप। कुछ ने सुझाव दिया कि एक अधिक अभिव्यंजक मान्यता पुस्तकालय विकसित किया जाए जो requiredकुछ और उन्नत के साथ-साथ जाँच कर सके name.length > 10, जबकि एक बेहतर विफलता मॉडल होना भी सुनिश्चित करता है।

Proto3 कुल मिलाकर सादगी का पक्ष लेता है, और requiredहटाना सरल है। लेकिन हो सकता है कि requiredअन्य विशेषताओं के साथ संयोजित होने पर, प्राइमो 3 के लिए संयुक्त भावना को हटा दिया जाए, जैसे कि प्राथमिकताओं के लिए फ़ील्ड उपस्थिति को हटाना और डिफ़ॉल्ट मानों को हटाना।

मैं एक प्रोटॉफ डेवलपर नहीं हूं और इस विषय पर किसी भी तरह से आधिकारिक नहीं हूं, लेकिन मुझे अभी भी उम्मीद है कि स्पष्टीकरण उपयोगी है।


23
हां। आवश्यक फ़ील्ड के साथ उन चीज़ों की यह विस्तृत व्याख्या देखें जो बुरी तरह से गलत हो सकती हैं: capnproto.org/…
Kenton Varda

8
वैकल्पिक हटाया नहीं गया है; प्रोटो 3 में सब कुछ वैकल्पिक है। लेकिन हां, आदिम के लिए फ़ील्ड दृश्यता (has_field) हटा दी गई है । आप क्षेत्र दृश्यता उपयोग की जरूरत है wrappers.proto जो जैसे संदेश है StringValue। चूंकि वे संदेश हैं, has_field उपलब्ध है। यह प्रभावी रूप से "मुक्केबाजी" है जो कई भाषाओं में आम है।
एरिक एंडरसन

9
इसके विपरीत, ऐसा लगता है जैसे "वैकल्पिक" को प्रोटो 3 में हटा दिया गया था। हर क्षेत्र मौजूद है, और एक डिफ़ॉल्ट मान से भरा है। आपके पास यह जानने का कोई तरीका नहीं है कि उपयोगकर्ता द्वारा या डिफ़ॉल्ट रूप से आदिम फ़ील्ड भरा गया था। संदेश फ़ील्ड, जो मूल रूप से संकेत हैं, वैकल्पिक हैं, इसमें उनका एक शून्य मान हो सकता है।
वैग्रांट

14
मुझे लगता है कि प्रोटोबुफ़ एक ऐसी भाषा है जिसे स्पष्ट रूप से लौ युद्धों को शुरू करने के लिए डिज़ाइन किया गया है
रैंडी एल

5
लगता है कि ज्यादातर लोग अपने एपीआई के संस्करण नहीं चाहते हैं। "पिछड़ी संगतता" के लिए सब कुछ वैकल्पिक करना उनके लिए आसान है।
होलोसेओ

41

आप इस प्रोटोबुफ़ गीथूब मुद्दे में स्पष्टीकरण पा सकते हैं :

हमने प्रोटो 3 में आवश्यक फ़ील्ड्स को गिरा दिया क्योंकि आवश्यक फ़ील्ड्स को आमतौर पर हानिकारक माना जाता है और प्रोटोबॉफ़ की संगतता शब्दार्थ का उल्लंघन करता है। प्रोटोबुफ़ का उपयोग करने का पूरा विचार यह है कि यह आपको नए / पुराने बायनेरिज़ के साथ पूरी तरह से आगे / पिछड़े संगत होने के दौरान अपनी प्रोटोकॉल परिभाषा से फ़ील्ड जोड़ने / हटाने की अनुमति देता है। आवश्यक फ़ील्ड हालांकि इसे तोड़ते हैं। आप कभी भी .proto परिभाषा में आवश्यक फ़ील्ड नहीं जोड़ सकते, और न ही आप किसी मौजूदा आवश्यक फ़ील्ड को सुरक्षित रूप से निकाल सकते हैं क्योंकि ये दोनों कार्य तार संगतता को तोड़ते हैं। उदाहरण के लिए, यदि आप .proto परिभाषा में एक आवश्यक फ़ील्ड जोड़ते हैं, तो नई परिभाषा के साथ निर्मित बायनेरिज़ पुरानी परिभाषा का उपयोग करके क्रमबद्ध डेटा पार्स नहीं कर पाएंगे क्योंकि आवश्यक फ़ील्ड पुराने डेटा में मौजूद नहीं है। एक जटिल प्रणाली में जहां। प्रोटो परिभाषाएँ सिस्टम के कई अलग-अलग घटकों में व्यापक रूप से साझा की जाती हैं, आवश्यक फ़ील्ड को जोड़ने / हटाने से सिस्टम के कई हिस्सों को आसानी से नीचे लाया जा सकता है। हमने कई बार इसके कारण उत्पादन के मुद्दों को देखा है और आवश्यक फ़ील्ड को जोड़ने / हटाने के लिए Google के अंदर हर जगह बहुत अधिक प्रतिबंधित है। इस कारण से हमने प्रोटो 3 में आवश्यक क्षेत्रों को पूरी तरह से हटा दिया।

"आवश्यक" को हटाने के बाद, "वैकल्पिक" केवल अनावश्यक है, इसलिए हमने "वैकल्पिक" को भी हटा दिया।


6
मुझे नहीं मिला; deserializing के बाद और deserialization पर एक संदेश छोड़ने के बीच क्या अंतर है? पुराने क्लाइंट द्वारा इसे हटा दिया जाएगा क्योंकि इसमें एक फ़ील्ड नहीं है जिसकी आवश्यकता है (जैसे आईडी)।
शमूएल एच।

6
मैं @ शमूएलएच के साथ सहमत होने के लिए इच्छुक हूं। आवश्यक फ़ील्ड एक या एक अन्य तरीके से एपीआई का एक हिस्सा बनने जा रहे हैं। ठीक है कि दोनों पक्षों को दिए गए सिंटैक्स के माध्यम से स्वचालित रूप से समर्थित है, या बैकएंड में छिपा हुआ है, यह अभी भी वहां है। साथ ही इसे एपी परिभाषा में दिखाई दे सकता है
क्रंचर

7
मैं @ शमूएलएच से पूरी तरह सहमत हूं। एक एपीआई या किसी अन्य तरीके से फ़ील्ड की आवश्यकता होती है और ग्राहक को यह जानने के लिए उपयोगी होता है। यह मुझे लगता है कि हम अभी तक अभी तक संस्करण नहीं मिला है।
संरक्षक

6
@ शमूएलएच के लिए एक और वोट। यदि आप अपने एपीआई को बैकवर्ड-असंगत तरीके से (आवश्यक फ़ील्ड जोड़कर) बदलते हैं, तो निश्चित रूप से आप चाहते हैं कि आपका पार्सर यह पता लगाए? अपने एपीआई संस्करण! तुम भी पूरी तरह से Protobuf में कर सकते हैं यदि आप चाहते हैं, का उपयोग कर oneof { MessageV1, MessageV2, etc. }
टिमम्मा

1
यह शुरू में आवश्यक क्षेत्र होने का औचित्य नहीं दे सकता था। और एक आवश्यक फ़ील्ड जोड़ना असंगत परिवर्तन है और आमतौर पर प्रोटोकॉल संस्करण परिवर्तन (यानी एक नया संदेश प्रकार) द्वारा नियंत्रित किया जाना चाहिए।
कण
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.