问题标签 [natural-key]

我在 django 上有这个模型，声明了 natural_keys 函数。

当我进行获取评论查询时，我想要完整的回复，包括评论详细信息、一些书籍详细信息和个人资料详细信息（包括图片）。一切都很好，除非我希望使用自然键序列化配置文件 mainimg。

错误响应是

不是 JSON 可序列化的

执行此操作时：

无论如何，我可以在序列化的同一响应对象上获得评论查询的多媒体 url？

谢谢。

使用这样的表模式有什么好处：

或者约束本身是否应该是主键，如下所示：

免责声明：这与其他主题不同。

我们在使用自然键时面临的一个缺点是，如果业务逻辑发生变化并且我们需要更改一个键，我们需要将这种更改传播到所有链接表中。

但是，使用ON UPDATE CASCADE声明，我们可以让 DBMS 在我们更改键值时为我们传播更改。

我不明白的是：这种方法有什么缺点？是否存在使用ON UPDATE CASCADE对数据库有风险的情况？

因为如果不是，那么如果在某种情况下，使用代理键的唯一原因是更容易更改业务自然键，那么ON UPDATE CASCADE应该使用而不是将所有表转换为代理键。

我正在设计一个使用自然键作为资源标识符的 API 端点。

我的服务公开了一个 Update(...) 操作，该操作会导致一个 SQL UPDATE 查询，该查询可能会更改此键，即

当使用不可变代理键时，我有

但是由于 newData 现在可以包含一个键，因此可以移动资源。

是否可以使用 201 和 Location 标头响应 PUT 到新资源？这对于 POST 请求是正常的，但与 PUT 似乎相反。带有新键的 PUT 实际上会导致请求 URI 处的 DELETE（根据服务器状态）和其他某个 URI 处的 PUT/POST。

另一方面，也许我根本不应该使用 PUT。RFC 2616 说“PUT 请求中的 URI 标识了请求中包含的实体”。在关系方面，如果新密钥与旧密钥不匹配，则请求 URI 不会识别封闭的资源。但这并不是那么简单。封闭的资源是请求 URI 的替代品，因此在某些上下文中（特别是由代理键具体化的那个），URI 确实标识了封闭的实体。

我可以在这里使用 POST，因为这似乎没有违反任何规则，但是在任何地方使用 POST 似乎又快又松。

我有一个包含多个模型的项目，所有这些模型都在实现自然键。其中大多数都在工作，但是当我使用自然键导出时，有一个模型（到目前为止）拒绝加载。

注意：如果我在导出时不使用自然键，它可以工作。

不会加载的模型是CampaignTransaction， Campaign 有效。

这是我的模型和经理：

这是输出python manage.py dumpdata donations --database test --indent=4 --natural-foreign > xx.json：

然后我尝试使用python manage.py loaddata --database test xx.json我收到错误重新加载它：

它似乎在抱怨空值，但我看不到缺少什么。从夹具。

我没有我想要的对象的 id，因为它们是由bulk_create: 创建的，并且bulk_create不返回带有 id 的对象，所以我需要通过它们的自然键来获取它们。

是否可以通过自然键过滤来获取对象？我在文档中什么也没找到。

我们已经可以做到：

我想要与自然键相同的东西：

我的模型如下所示：

- 编辑 -

最终，我找到了一个更快的解决方案来取回由bulk_created: 按最后创建的对象过滤！我已经比较了这与通过自然键获取对象之间的时间，它肯定更快。

我有一个使用自然主键的临时表。此表存储一个导入的 CSV 文件，它是一个历史表，用于跟踪每次导入。我开始看到主键字段的一些重复项（在我导入的 CSV 中），并希望保留这些记录而不丢失历史表的功能。我目前在导入之前手动从 CSV 中删除行。

是否可以有一个由自然键和代理键组成的主键？自然键已被使用，并且自动递增键仅在存在重复的自然 id 时才会递增。