我已经阅读了一些关于CouchDB的内容,我真的很感兴趣它是"仅附加".我可能误解了这一点,但据我了解,它有点像这样:
数据在时间t0添加到DB,告知ID为1的用户是"Cedrik Martin"
询问"ID为1的用户的名称是什么？"的查询 返回"Cedrik Martin"
在时间t1,对DB进行更新,告知:"具有ID 1名称的用户是Cedric Martin"(将"k"改为"c").
再次询问"ID为1的用户名称"的查询现在返回"Cedric Martin"
这是一个愚蠢的例子,但这是因为我想了解一些关于CouchDB的基本知识.
看到更新是使用数据库末尾的附加进行的,是否可以查询数据库"就像它在时间t0",没有做任何特别的事情？
我可以问CouchDB "在时间t0,ID为1的用户的名字是什么？" ？
编辑第一个答案是非常有趣的,所以我有一个更精确的问题:只要我不"压缩"CouchDB,我就可以编写以某种方式"引用透明"的查询(即它们总是产生同样的结果)？例如,如果我查询"修订版r的文档d",只要我没有压缩数据库,我保证总能得到相同的答案吗？
Rob*_*son 30
也许CouchDB最常犯的错误就是相信它为您的数据提供了一个版本控制系统.它不是.
压缩将删除所有文档的所有非最新修订,并且复制仅复制任何文档的最新修订.如果您需要历史版本,则必须使用任何对您有用的方案将其保留在最新版本中.
如上所述,"_rev"是一个不幸的名字,但没有其他任何一个词被提出更清楚.之前已经提出过"_mvcc"和"_mcvv_token".两者的问题在于,对那里发生的事情的任何描述将不可避免地包括"旧版本保留在磁盘上直到压缩",这仍然意味着它是用户版本控制系统.
要回答"我可以询问CouchDB"这个问题,在时间t0,ID为1的用户名称是什么？"？",简短回答是"否".长的回答是"是的,但后来它将无法工作",这只是说"不"的另一种方式.:)
正如已经说过的，这在技术上是可行的，你不应该指望它。它不仅涉及压缩，还涉及复制，这是 CouchDB 的最大优势之一。但是，是的，如果您从不压缩并且不复制，那么您将始终能够获取所有文档的所有先前版本。我认为它不适用于查询，但它们不适用于旧版本。
基本上，称其为“rev”是 CouchDB 设计中最大的错误，它应该被称为“mvcc_token”或类似的名称——它实际上只实现了 MVCC，并不意味着用于版本控制。
| 归档时间： |
|
| 查看次数： |
5290 次 |
| 最近记录： |