【发布时间】：2011-12-26 12:48:27
【问题描述】：
使用 CouchDB 为客户创建托管应用程序。我有一个我工作的开发数据库，以及每个客户端的单独数据库。效果很好，问题是当我对开发进行更改时，我必须手动将视图代码复制到每个单独的数据库中。现在我有 2 个客户很好。但我的希望是增长到 100 个客户。一个小小的改变可能需要很长时间！
关于仅复制视图，我是否遗漏了一些简单的东西？
谢谢！
【问题讨论】：
标签： views nosql couchdb replication
【发布时间】：2011-12-26 12:48:27
【问题描述】：
【讨论】：
这是我通常的工作方式。
- 我有本地开发数据库。创建和更新我的设计文档（包含视图）。
- 拥有一个所有客户端都可以看到的生产部署数据库。我通常使用iriscouch。在此数据库中不保留任何数据。
- 设置客户端时，请确保设置从 #2 到此客户端 db 的单向复制。
所以为了部署到所有客户端，我将我最新的设计文档放在 master 上，然后所有客户端都会更新。对此有一些警告。您必须确保在部署到主数据库时遵守修订，以便客户端数据库知道要更新。
这是大师杰森·史密斯的话：
好方法：使用 _rev
我认为您的应用程序有一个“升级”的概念 修改为另一个。有暂存或开发代码，并且有 是生产代码。您定期将开发代码提升到 生产。这听起来像两个 Git 分支，也听起来像 两个文档 ID。 （或两组 doc id。）
您可以在临时文档中整天测试和重构您的代码 （_设计/开发）。但是在生产中（_design/pro），它就像一个长 吉特历史。从前一个版本构建的每个版本，到 时间的开始。
如果要推广_design/dev，最新的部署是 _rev=4-abcdef。所以这将是部署的第五个修订版，对吧？ 嘿！停止阅读“_rev”字段！但是，是的，可能。
复制 /db/_design/dev 目的地：_design/pro?rev=4-abcdef
{"id":"_design/pro","rev":"5-12345whatever"}
请注意，每个部署的 _design/pro 都是从另一个构建的，所以它 复制时自然会飘到奴隶身上。
在现实生活中，你可能已经添加了一个中间步骤，推送设计文档 在实际发布它们之前到生产服务器。一推， 沙发需要多长时间才能建立新的观点？答案是， “天哪，谁知道呢？”
因此你必须将 _design/dev 复制到 _design/staging 然后 把它推到野外。然后你必须查询它的视图，直到 您对它们的新鲜和快速感到满意。 （你可以比较 /db 中的“update_seq”与 /db/_design/ddoc/_info 中的“update_seq”）。 只有这样你才能从 _design/staging 复制到 _design/pro 和 让它传播出去。
它并不像听起来那样令人困惑。但是为了简化流程，可以使用Reupholster （我承认，我已经写了这个工具）。它主要用于 couchapps，但即使您只是在推广设计文档，也可能值得您使用 reupholster 部署到您的主数据库。 Reupholster 在设计文档中添加了一些方便的信息，例如日期/时间 svn 或 git 信息。这样，当您查看客户数据库时，您就可以知道他们在哪个设计文档上。
祝你好运
【讨论】：
-
+1。但我只是玩禅道的高手。 en.wikipedia.org/wiki/Zendo_%28game%29