本文是小编为大家收集整理的关于如何从设计的角度处理CouchDB修订?的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
我可以说，couchdb修订版本不应像文档版本中的修订一样对待该单词的感觉.从浏览其他帖子，它们似乎被视为存在的瞬态数据，直到调用粗粒紧凑>操作.
.我的问题是，如果我有兴趣使用couchdb维护文档以及这些文档的版本历史，那么我应该允许使用CouchdB修订本来对其进行本地处理，或者我应该在上面构建一层那将在紧凑的操作中幸存吗?
我在想后者，仅仅是因为沙发没有复制文档的修订，而仅复制最新更新.这使我认为修订是一个误导的名称，因为它更像是稳定复制的数据结构.
推荐答案
您必须构建该层，因为CouchDB修订版是不是用于您的数据的版本控制系统.
'修订'具有误导性，"版本"也是如此，到目前为止建议的每个名称也是如此.欢迎建议，如果只是为了确认命名多么棘手.
问题描述
Near as I can tell, CouchDB revisions are not to be treated like revisions in the document versioning sense of the word. From glancing at other posts, they seem to be regarded as transient data that exists until a coarse-grained compact operation is called.
My question is, if I am interested in using CouchDB to maintain documents, as well as a version-history of those documents, should I allow that to be handled natively by CouchDB revisions, or should I build a layer on-top that will survive a compact operation?
I am thinking the latter, simply because Couch does not replicate revisions of documents, only the latest update. This makes me think revision is a mis-leading name, as it's more of a data structure for stabilizing replication.
推荐答案
You must build that layer because couchdb revisions are not a versioning system for your data.
'revision' is misleading, and so is 'version' and so is every name that has been suggested so far. Suggestions welcome, if only to confirm how tricky naming this is.
更多相关问答
联系站长