如何将必需的节俭字段设为可选? [英] How do I make a required thrift field optional?

问题描述

在 thrift 中制作 required 字段 optional 的最佳过程是什么?例如，我有一个结构...

What is the best process for making a required field optional in thrift. For example, I have a struct...

struct Message {
    1: required double userID;
    2: required string content;
    ...
} 

...但我想让 content 成为可选的.

... but I want to make content optional.

澄清一下，我已经有使用这个结构的消费者，所以我需要在不破坏这些消费者的情况下更新它.分阶段升级很好(即 ​​- 添加新的 optional 字段，更新下游客户端，然后删除 - 或停止使用 - 旧的 required 字段).>

To clarify, I already have consumers that use this struct, so I would need to update it without breaking those consumers. A staged upgrade is fine (ie - add a new optional field, update the downstream clients, then remove--or stop using--the old required field).

推荐答案

你不能，因为俗话说必需是永远.以下是 Diwaker Gupta 极力推荐的 "Missing Guide" 的引述.它几乎明确了为什么在使用 required 之前应该三思而后行(至少):

You can't, because as the saying goes required is forever. The following is a quote from Diwaker Gupta's highly recommendable "Missing Guide". It pretty much nails it down why one should think twice (at least) before using required:

您应该非常小心地根据需要标记字段.如果在某个时候您希望停止编写或发送必填字段，将字段更改为可选字段会出现问题 — 旧读者会认为没有此字段的消息是不完整的，并且可能会无意中拒绝或丢弃它们.你应该考虑写针对您的缓冲区的特定于应用程序的自定义验证程序反而.有些人得出的结论是，使用 required 做的更多弊大于利；他们更喜欢只使用可选的.然而，这种观点不是通用的.

Required Is Forever

You should be very careful about marking fields as required. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field — old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally. You should consider writing application-specific custom validation routines for your buffers instead. Some have come the conclusion that using required does more harm than good; they prefer to use only optional. However, this view is not universal.

恐怕唯一的选择是弃用整个结构并创建一个新结构.

I'm afraid that the only option is to deprecate the entire struct and create a new one.

除此之外，实际上还有三个要求度，其中只有两个有关键字:

In addition to that, there are in fact three degrees of requiredness, only two of them have keywords:

• required:读取时必须存在，写入时必须设置
• optional:可以设置也可以不设置，完全可选
• "default": 读取时可能不存在，始终写入(除非它是 null 指针)

• required: must exist on read, must be set on write
• optional: may or may not be set, entirely optional
• "default": may not exist on read, always written (unless it is a null pointer )

当 required 和 optional 均未指定时，隐式应用默认"要求.

The "default" requiredness is applied implicitly when neither required nor optional are specified.

我们可以清楚地看到，如果我们查看事物的兼容性站点，对于required 的限制是相当严格的.即使向结构添加新的 required 字段也可能导致不兼容，例如如果新客户端正在从旧服务器读取数据(反之亦然)，因为新的 required 字段不在旧 impl 写入的数据中，而是新 impl 所期望的.

As one clearly sees, the restrictions for required are rather strict if we look at the compatibility site of things. Even adding a new required field to a struct may lead to incompatibility, e.g. if a new client is reading data from an old server (or vice versa), because the new required field is not in the data written by the old impl, but expected by the new impl.

这篇关于如何将必需的节俭字段设为可选?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！