Protocol Buffers : Language Guide (proto3) - Updating A Message Type

• Protocol Buffers : Language Guide (proto3) - Updating A Message Type

Index

• Defining A Message Type
• Scalar Value Types
• Default Values
• Enumerations
• Using Other Message Types
• Nested Types
• Updating A Message Type
• Unknown Fields
• Any
• Oneof
• Maps
• Packages
• Defining Services
• JSON Mapping
• Options
• Generating Your Classes

Updating A Message Type 메시지 유형 업데이트 중

If an existing message type no longer meets all your needs – for example, you'd like the message format to have an extra field – but you'd still like to use code created with the old format, don't worry! It's very simple to update message types without breaking any of your existing code. Just remember the following rules:
기존 메시지 유형이 더 이상 사용자의 모든 요구를 충족하지 않는 경우(예: 메시지 형식에는 추가 필드가 포함되기를 원하지만, 이전 형식으로 작성된 코드를 사용하고자 하는 경우) 걱정하지 마라! 기존 코드를 제거하지 않고 메시지 유형을 업데이트하는 것은 매우 간단하다. 다음 규칙을 기억하라.

• Don't change the field numbers for any existing fields.
  기존 필드의 필드 번호를 변경하지 마라.
• If you add new fields, any messages serialized by code using your "old" message format can still be parsed by your new generated code. You should keep in mind the default values for these elements so that new code can properly interact with messages generated by old code. Similarly, messages created by your new code can be parsed by your old code: old binaries simply ignore the new field when parsing. See the Unknown Fields section for details.
  새 필드를 추가할 경우 "이전" 메시지 형식을 사용하여 코드로 일련화된 모든 메시지는 새로 생성된 코드로 계속 구문 분석할 수 있다. 새 코드가 이전 코드에서 생성된 메시지와 적절하게 상호 작용할 수 있도록 이러한 요소에 대한 기본값을 고려해야 한다. 마찬가지로 새 코드에서 생성된 메시지는 이전 코드로 분석할 수 있습니다. 이전 이진 파일은 구문 분석할 때 새 필드를 무시한다. 자세한 내용은 알 수 없는 필드 섹션을 참조하라.
• Fields can be removed, as long as the field number is not used again in your updated message type. You may want to rename the field instead, perhaps adding the prefix "OBSOLETE_", or make the field number reserved, so that future users of your .proto can't accidentally reuse the number.
  업데이트된 메시지 유형에서 필드 번호를 다시 사용하지 않는 한 필드를 제거할 수 있다. 대신 필드 이름을 바꾸거나 접두사 "OBSOLETE_"를 추가하거나 필드 번호를 예약하여 나중에 .proto의 사용자가 실수로 번호를 재사용하지 못하도록 할 수 있다.
• int32, uint32, int64, uint64, and bool are all compatible – this means you can change a field from one of these types to another without breaking forwards- or backwards-compatibility. If a number is parsed from the wire which doesn't fit in the corresponding type, you will get the same effect as if you had cast the number to that type in C++ (e.g. if a 64-bit number is read as an int32, it will be truncated to 32 bits).
  int32, uint32, int64, uint64 및 bool은 모두 호환된다. – 즉, 전후 호환성을 유지하면서 이러한 유형 중 하나에서 다른 유형으로 필드를 변경할 수 있다. 해당 유형에 맞지 않는 와이어에서 숫자를 구문 분석하는 경우, C++에서 해당 유형의 숫자를 캐스팅한 것과 동일한 효과를 얻는다(예: 64비트 숫자를 읽은 경우).
• sint32 and sint64 are compatible with each other but are not compatible with the other integer types.
  sint32와 sint64는 서로 호환되지만 다른 정수 유형과 호환되지 않는다.
• string and bytes are compatible as long as the bytes are valid UTF-8.
  문자열과 바이트는 바이트가 유효한 UTF-8인 한 호환 가능하다.
• Embedded messages are compatible with bytes if the bytes contain an encoded version of the message.
  포함된 메시지는 바이트에 암호화된 메시지 버전이 포함되어 있으면 바이트와 호환된다.
• fixed32 is compatible with sfixed32, and fixed64 with sfixed64.
  고정32는 sfixed32와 호환되고 sfixed64는 sfixed64와 호환된다.
• enum is compatible with int32, uint32, int64, and uint64 in terms of wire format (note that values will be truncated if they don't fit). However be aware that client code may treat them differently when the message is deserialized: for example, unrecognized proto3 enum types will be preserved in the message, but how this is represented when the message is deserialized is language-dependent. Int fields always just preserve their value.
  enum은 int32, uint32, int64 및 uint64와 호환됩니다(잘리지 않으면 값이 잘린다). 그러나 메시지가 감응될 때 클라이언트 코드가 이를 다르게 처리할 수 있습니다. 예를 들어, 인식되지 않은 프로토3 열거 유형은 메시지에 보존되지만 메시지가 종속된 경우 이러한 유형이 어떻게 표현되는지에 유의하라. Int 필드는 항상 해당 가치를 유지한다.
• Changing a single value into a member of a new oneof is safe and binary compatible. Moving multiple fields into a new oneof may be safe if you are sure that no code sets more than one at a time. Moving any fields into an existing oneof is not safe.
  단일 값을 새 값의 구성원으로 변경하는 것은 안전하며 이진 호환된다. 한 번에 두 개 이상의 코드가 설정되지 않은 경우 여러 필드를 새 필드 중 하나로 이동하는 것이 안전할 수 있다. 기존 필드로 이동하는 것은 안전하지 않다.