需要字符串的 DocumentDB“id”字段限制存在哪些解决方法？答案

【问题标题】：What workarounds exist for DocumentDB "id" field restriction which requires string?需要字符串的 DocumentDB“id”字段限制存在哪些解决方法？
【发布时间】：2017-03-02 08:20:38
【问题描述】：

我们有一个简单的案例，我们希望直接从 API 提供者 (Github) 获取 JSON 文档并将它们存储在 DocumentDB 集合中。不幸的是，文档恰好有一个数字的“id”字段，因此在尝试创建文档时会导致错误。

这一定是一种常见的情况，我发现一个帖子似乎表明“最糟糕”。但是，我正在寻找确认。我有点希望我不必为 ID 字段编写自定义处理，它会在每次存储和检索操作时修改所有文档，只是为了使它们与 DocumentDB 兼容。

https://social.msdn.microsoft.com/Forums/vstudio/en-US/26386227-4aa2-48d5-9cc4-547caef18fb5/id-field-work-around-help-needed?forum=AzureDocumentDB

【问题讨论】：

不确定我理解你所说的“最差”是什么意思 - DocumentDB id 属性只是一个字符串。为什么您需要在每次检索和写入时修改您的文档？似乎这只是您最初存储到 docdb 时需要做的事情。另外，如果您愿意，您可以随时添加自己的数字 id 属性。

标签： azure azure-cosmosdb

【解决方案1】：

就像我在 cmets 中提到的，我不确定主要问题是什么，但 DocumentDB 的 id 属性是一个字符串。在保存到 DocumentDB 之前，您需要将 GitHub 内容的数字 id 属性转换为字符串。或者，您可以创建自己的数字属性（id 除外）来维护数字数据类型，以供将来查询。

您不能在集合本身内将id 的数据类型从字符串更改为数字。

【讨论】：

【解决方案2】：

感谢您的反馈。我认为我提供的文章中的建议比实现逻辑来改变恰好被命名为“id”并且恰好不是仅用于使用 DocumentDB 的字符串的任何字段的类型更有吸引力。一般来说，我是 NoSQL 的新手，但我也可以看到将 DocumentDB 上的文档封装到基于类型名称的外部对象中的一些其他好处。因此，如果我正在使用存储库，JSON 的形状将如下所示：

{
  "repository": {
      "id": "Id from github",
      "foo": "bar"
  },
  "id" : "document-db-id"
}

在我的整个应用程序中使用这种包装方法作为惯例对我来说很有意义。我只需要在整个应用程序中为 DocumentDB 操作添加一个“类型”参数。

我也看到了一些缺点。例如，它可能需要在 DocumentDB 的任何实体框架和为 API 提供数据模型的 SDK 之间有一个层。

如果有人对在任何类型的 NOSQL 的“类型”容器中包装文档有任何经验或建议，我们将不胜感激。

【讨论】：