Protobuf आवश्यक फ़ील्ड और डिफ़ॉल्ट मान

Question

मैं नया हूँ Protobuf करने और मैं निम्नलिखित तुच्छ उदाहरण

message Entry { 
    required int32 id = 1; 
} 

C++ कोड द्वारा इस्तेमाल किया पर विचार शुरू कर दिया है

#include <iostream> 
#include "example.pb.h" 
int main() { 
    std::string mySerialized; 
    { 
    Entry myEntry; 
    std::cout << "Serialization succesfull " 
       << myEntry.SerializeToString(&mySerialized) << std::endl; 
    std::cout << mySerialized.size() << std::endl; 
    } 
    Entry myEntry; 
    std::cout << "Deserialization successfull " 
      << myEntry.ParseFromString(mySerialized) << std::endl; 
} 

यहां तक ​​कि अगर "आईडी" क्षेत्र है आवश्यक है, क्योंकि यह सेट नहीं किया गया है, serialization बफर का आकार 0 (??) है।

जब मैं संदेश deserialize एक त्रुटि होती है:

[libprotobuf ERROR google/protobuf/message_lite.cc:123] Can't parse message of type "Entry" because it is missing required fields: id 

यह एक सामान्य व्यवहार है?

फ्रांसेस्को

ps- अगर मैं 0 मान "आईडी" प्रारंभ, व्यवहार अलग है

pps- SerializeToString समारोह सच देता है, ParseFromString रिटर्न झूठी

Answer 1

मुझे लगता है कि न मैं वास्तव में आपके प्रश्न को समझता हूं, लेकिन मुझे किसी भी तरह उत्तर में जाना होगा। उम्मीद है कि यह आपको किसी तरह से या दूसरे में मदद करता है :)

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

यह देखता है कि नंबर 1 के साथ चिह्नित फ़ील्ड आवश्यक है, और has_id() विधि गलत लौट रही है। तो यह संदेश बिल्कुल पार्स नहीं करेगा।

developer guide में यह आवश्यक फ़ील्ड का उपयोग न करने की सलाह दी जाती है।

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

इसके अलावा

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