azure-table-storage - Azure 表存储和 Null 属性值 - 误导性文档？

Question

该文档指出以下内容：

表服务不会为属性保留空值。查询实体时，上述属性类型都是不可为空的。在编写实体时，上述属性类型都是可以为空的，任何具有空值的属性都被视为有效负载不包含该属性。

我将我感兴趣的文本加粗。

乍一看，在我看来，类型化的实体属性永远不会null在从一行中读取一个实体之后。这当然是不真实的，经过测试验证。

我显然误读了文档。该文档专门指的是 REST 响应的行为，所以真正发生的是 REST 响应只是省略了它没有存储值的属性。因此，通过不保留任何null值，REST 结果中的任何属性都可以保证为非 null，而那些本来应该null存在的属性在响应中根本不存在（只要具有 null 属性的实体被替换，而不是合并，当写）。

因此，映射到ITableEntity实现的 REST 响应中缺少的属性必须被推断为null.

此外，为了确保null值实际上是“持久的”，必须替换实体而不是合并实体。

我对此的分析正确吗？

如果是，那么不应该更新文档以使这一点更清楚吗？似乎有点混乱。

标签： azure-table-storage

Answer 1

文档意味着nullvalue 属性不会被持久化在 Azure Storage Table service中，这与客户端库的实现无关。请注意，这是REST API 文档而不是客户端库文档。在客户端库的当前实现中，在反序列化来自 Azure 存储表服务的查询响应时，ITableEntity会保留其中缺少的属性。null

无论执行或操作如何，值属性都永远不会在服务端持久null化。replacemerge

例如，如果先前持久化的实体{"a":1, "b":2}在服务端，并且merge使用有效负载执行操作{"a":null, "b":3, "c":4}，则新持久化的实体将{"a":1, "b":3, "c":4}在服务端。作为比较，如果执行的操作是replace使用 payload {"a":null, "b":3, "c":4}，新持久化的实体将{"b":3, "c":4}在服务端。