Protobuf Grammar Detailed _protocol

The beginning of the article, first put a PROTOBUF definition syntax

Option Java_outer_classname = "studententity";  
Message Student {  
  required int32 id = 1;  
  Required String name = 2;  
  Optional String nickname = 3 [default= "];  
}  

One, message

Defining a data structure in PROTOBUF requires a keyword message, which is similar to the Java class. Second, identification number

In the definition of a message, each field equals an equal sign followed by a unique identification number, which is used to identify the fields during deserialization and cannot be changed once it is started. Third, the field rules

There are three types of field rules:

Required: This rule stipulates that the value of the field in the body of the message must be set. Optional: The value of the field of the rule in the body of the message can exist or be empty, and optional fields can set the default value according to Defalut. Repeated: The rule field in the message body can exist multiple (including 0), which corresponds to a Java array. Iv. Types of data

Data types nothing to say, are common data types, see the table below

V. Enumeration and use of other message types

Option Java_outer_classname = "studententity";  
Message Student {  
  required int32 id = 1;  
  Required String name = 2;  
  Optional String nickname = 3 [default= "];  
  Enum age{
    male =1;
    Female =2;
    }
  Required age age=4;
  Required Class class=5;
} 

Message class{
  required int32 id=1;
  Required string name=2;
}

In addition, the message also supports the fields of the map type, declared as follows

Map<int32, string> m = N;

If you need to quote a message that is written in a different. proto file, you can introduce it through the import "Xxx.proto". Six, nesting

Option Java_outer_classname = "studententity";  
Message Student {  
  required int32 id = 1;  
  Required String name = 2;  
  Optional String nickname = 3 [default= "];  
  Enum age{
    male =1;
    Female =2;
    }
  Required age age=4;
  Message class{
  required int32 id=1;
  Required string name=2;
  }
  Required Class class=5;

Vii. Option

Before the message definition can be configured by option, the commonly used two option:option java_package= "xxx/xxx" specifies the path option for Java file Generation Java_outer_classname= " XXX "This option has the generated Java class name

More options can refer to the update of the eight message

After the message is defined, if it needs to be modified, the following rules are required to ensure that prior serialization and deserialization can be compatible with new Message,message modifications: You cannot modify an identification number in an existing domain all newly added fields must be  optional  or  repeated. This means that the old serialization information can be parsed by the new code as long as it does not lose the required domain that is already defined. In order for the new code to parse the sequence provided by the old code normally, we need to add some default values to the new domain at the time of the update (the default value is not passed, just save locally, that is, different versions of the code may read different values for the same domain). Similarly, the serialized files produced by the new code can also be parsed by the old code, which ignores the newly added fields, which are not discarded when parsing, and which are serialized along with the other fields when the old code is serialized. Passes the serialized file to the new code. These new domains are also valid. Non-required fields can be deleted. However, the identification numbers of these deleted fields are not allowed to be used again. A required field can be transformed, extended or truncated when transformed, and the identity number and name are invariant. Int32, UInt32, Int64, UInt64 and bool are mutually compatible. This means that these types can be converted to each other, and are both forward and backward compatible. If we set a category that is not enough to represent numbers, a truncation similar to C + + will occur. Sint32 and Sint64 are mutually compatible, and are not compatible with other integer types when the UTF-8 encoding is compatible with the bytes nested message when encoded in the same way bytes fixed32 compatible sfixed32. FIXED64 compatible with SFIXED64. Optional compatible with repeated. The sender sends the repeated domain, which the user reads using the optional domain, and reads the last element of the repeated domain. Changing the default value is generally not a problem. It is worth noting that, as long as the user's version is not updated, the user is still reading the original default value without setting up the domain. Enumeration types are compatible with Int32, UInt32, Int64, UInt64 (note that truncation occurs if values and types do not match), so we need to be aware that the client may perform some non-enum processing of these values after parsing. Typically, an enum value that is not recognized (not within a collection defined by an enum) is discarded, and false is returned if the has method is used. Reading this value with the Getter method returns the first value of the enum list, if DEF is definedAult returns the value of default. All of the unrecognized elements in the repeated enum domain will be removed from the list unless it is an integer field that retains the value of the integer field. Therefore, we should pay attention to whether the range is exceeded when we promote an integer type as an enum type. In existing Java and C + + applications, when an unrecognized enum is removed, it is actually stored in the unknown domain (unknown fields) with other unrecognized elements. When the client resolves an unknown domain here, some strange behavior can occur if it is recognized. In the optional domain, the user can still read the original message after the original message has been parsed and the new data is written. In the repeated domain, the old values will appear after the newly added values, so their order is not fixed.