CouchDB 视图复制

发布于 2024-12-15 00:08:39 字数 192 浏览 2 评论 0原文

使用 CouchDB 为客户端创建托管应用程序。我有一个工作的开发数据库，以及每个客户端的单独数据库。效果很好，问题是当我在开发上进行更改时，我必须手动将视图代码复制到每个单独的数据库中。现在我有 2 个客户了。但我的希望是增加到 100 个客户。一个小小的改变可能会花费很长时间！

我是否错过了仅复制视图方面的一些简单内容？

谢谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

如此安好 2024-12-22 00:08:40

这是我通常的工作方式。

我有我的本地开发数据库。创建和更新我的设计文档（包含视图）。
拥有一个对所有客户端都可见的生产部署数据库。我通常使用 iriscouch。此数据库中不保留任何数据。
设置客户端时，请确保设置从 #2 到此客户端数据库的单向复制。

因此，为了部署到所有客户端，我将最新的设计文档放在主控上，然后所有客户端都会更新。对此有一些注意事项。您必须确保在部署到主数据库时遵守修订，以便客户端数据库知道要更新。

以下是大师 Jason Smith 的一句话：

好方法：与 _rev 合作
我认为你的应用程序有一个“升级”的概念
修订另一个。有暂存或开发代码，并且有
是生产代码。您定期推广开发代码
生产。这听起来像两个 Git 分支，也听起来像
两个文档 ID。（或两组文档 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 进行 HTTP 复制到 _design/pro 并
让其传播出去。

来源

它并不像听起来那么令人困惑。但为了简化流程，您可以使用 Reupholster
（我承认，这个工具是我写的）。它主要用于 couchapps，但即使您只是推广设计文档，使用 reupholster 部署到主数据库也可能是值得的。 Reupholster 在设计文档中添加了一些方便的信息，例如日期/时间 svn 或 git 信息。这样，当您查看客户数据库时，您可以知道他们所在的设计文档。

祝你好运

Here is how I usually work.

I have my local dev db. create and update my design docs (containing the views).
Have a production deployment db that will be visible to all the clients. I usually use iriscouch. Keep no data in this db.
When setting up a client, make sure you setup one way replication from #2 to this client db.

So to deploy to all clients, I put my latest design docs on the master, then all the clients will then be updated. There are some caveats to this. You have to make sure when you deploy to the master db, that you respect the revisions, so the client dbs will know to update.

Here is a quote from the master, Jason Smith:

The Good Way: Work with _rev
I think your application has a concept of "upgrading" from one
revision to another. There is staging or development code, and there
is production code. Periodically you promote development code to
production. That sounds like two Git branches and it also sounds like
two doc ids. (Or two sets of doc ids.)
You can test and refactor your code all day long, in the temporary doc
(_design/dev). But in production (_design/pro), it's just like a long
Git history. Every revision built from the one previous, to the
beginning of time.
If you want to promote _design/dev, the latest deploy is
_rev=4-abcdef. So this will be the fifth revision deployed, right?
Hey! Stop reading the "_rev" field! But yeah, probably.
COPY /db/_design/dev
Destination: _design/pro?rev=4-abcdef
{"id":"_design/pro","rev":"5-12345whatever"}
Notice that each deployed _design/pro builds from the other, so it
will naturally float out to the slaves when they replicate.
In real-life, you may have add a middle step, pushing design documents
to production servers before actually publishing them. Once you push,
how long will it take couch to build new views? The answer is,
"Christ, who knows?"
Therefore you have to copy _design/dev to _design/staging and then
push that out into the wild. Then you have to query its views until
you are satisfied that they are fresh and fast. (You can compare
"update_seq" from /db vs. "update_seq" from /db/_design/ddoc/_info).
And only then do you HTTP copy from _design/staging to _design/pro and
let that propagate out.

Source

Its not as confusing as it may sound. But to simplify the process, you can use Reupholster
(I admit, I have written this tool). It is mainly for couchapps, but even if you are just promoting design docs, it might be worth you just using reupholster to deploy to your master db. Reupholster adds in some handy info to the design doc, like date/time svn or git info. That way when you look at a clients db you can tell which design doc they are on.

Good luck

回复收藏 0 原文