Thinking (88): Use protobuf custom options for multi-version management of data

Data multi-version management

In the production environment of the project, the data is iterated for many times, and the data structure may also be expanded.

There needs to be a way to identify such changes and to do data version upgrades and other requirements

Common ideas, such as: the data in the DB has a version number, and the data structure definition in the code also determines the latest version in some way

Recently seen a more elegant way also available in Etcd

I did the next exercise for reference, and recorded one or two

Entry Multiversion Management for WAL in Etcd

Entry in the WAL file in the Etcd version iteration, resulting in changes to the data structure as the version iterates

Etcd has such a requirement: when the Entry version in its own code is lower than that in the WAL file, it is regarded as an error and the service is closed

Etcd uses protobuf customization options to achieve multi-version definition of Entry

For example:

enum EntryType {option (versionpb.etcd_version_enum) = "3.0";EntryNormal = 0;EntryConfChange = 1; // corresponds to pb.ConfChangeEntryConfChangeV2 = 2 [(versionpb.etcd_version_enum_value)="3.4"]; // corresponds to pb.ConfChangeV2}message Entry {option (versionpb.etcd_version_msg) = "3.0";optional uint64 Term = 2 [(gog