小桀
reserved的应用

reserved的应用

使用如下代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


syntax = "proto3";

message SearchRequest2 {
  reserved 1, 2;
  reserved "result_per_page";
  string         query           = 1;
  repeated int32 page_number     = 2;
  repeated int32 result_per_page = 3;
}

编辑器会报错，且无法正常编译：

2021-07-29-11-47-20

小结

需要思考一下，如何在实践中应用相关的技术。删除一行消息字段是一件非常简单的事情，根本就没有办法约束开发在删除一个字段的定义时补上一个reserved。所以为了让开发未来想起该消息类型需要补上一个reserved，我们需要一定需要进行版本管理（这是必要会进行版本管理的）。

但是即使是使用了版本管理，我们也大多数情况是在事故发生后才知道需要补上这个字段，这个时候已经给我们的生产环境带来了影响。我趋于怎么做，我趋于开发脚本，结合版本管理工具，自动完成reserver字段的添加和管理。

大致思路是这样的，我们每次提交proto文件，我们CI工具将会拉取当前的代码和和上一个版本（由CI工具记录，并非严格意义上的上一次提交）的代码，分析删除了哪些字段，然后进行自动添加上reserved字段，再编译成需要的代码文件。

最后，我还需要思考下，protoBuf是否新旧协议的兼容，如果兼容，我又该如何做，我又该如何管理我的项目。

对消息类型进行更新

添加新字段时，旧消息可以被新代码解析，解析时旧消息中没有的字段将会被设置为默认值。旧代码也可以解析新的消息，在解析的过程中会自动忽略新增加的字段。所以在解析的过程中，我们需要注意字段的默认值。删除字段的原理类似。

字段名似乎不会影响最终的解析结果，所以针对要删除的字段，我们可以将其重命名为OBSOLETE_fieldName，或者直接删除该字段，并使用reverse保留字段名和编号。

int32、uint32、int64、uint64和bool都兼容，可以从一种类型改为另一种，不会破坏向前向后的兼容性。如果解析出来的数据不适合该类型，在编程语言中将会进行强制类型转换。

。。。

后面知识太多了，感觉目前都用不到，往后再整理。