The Core API
这是章节会仔细的来探索CouchDB. 会展示所有的重要的实际的问题和聪明的处理方法. 我们会向你展示最佳实践并在一些常见的会遇到的问题是上指导你.
我们从重新回顾我们在前几个章节的操作开始, 看看这些操作的背后在做什么. 我们还会展示Futon在它的界面底下需要做些什么来提供给我们先前我们看到的美好特性.
这个章节同时是一个关于核心CouchDB API的介绍和一个参考. 如果你记不起来如何跑一个特殊请求或者为什么需要一些参数, 你总是可以回到这里来查找(我们可能是使用这一章节最多的用户.)
当我们在探索API时, 有时候我们需要绕一个弯路来解释一个特殊请求的原因. 对于我们来说, 这是一个告诉你为什么CouchDB这么工作的好机会.
API可以被分成下面的几个部分. 我们会分别来看它们:
数据库信息
这部分是基础的也是简单的. 它可以检查CouchDB是否正在工作. 它也可以作为一些需要特定版本CouchDB的库的安全保障. 我们会再一次用到`curl`这个工具.
curl http://127.0.0.1:5984/
CouchDB回应:
{“couchdb”:”Welcome”,”version”:”0.9.0″}
你会得到一个JSON字符串, 这个字符串, 如果把它作为你的编程语言的原生对象或者一个数据库解析, 你会得到一个welcome字符串和版本信息.
这不是非常有用, 但是它很好的展示了与CouchDB交互的一种方法. 你发送一个HTTP请求然后你会在HTTP回应里收到一个JSON字符串作为结果.
数据库
现在让我们做些更加有用的: 创建数据库. 严格的来说, CouchDB是一个数据库管理系统(DMS). 这意味着它可以有多个数据库. 一个数据库保存有”相关数据”的桶. 我们会在后面解释这到底意味着什么. 在实际中, 术语重叠了, 人们经常把DMS当成一个数据库, 也同时把一个在DMS里数据库当成DMS. 我们可能会顺着这种奇怪的现象, 不会被它搞混了, 通常, 能清楚的区分我们到底是在讲整个CouchDB还是一个在CouchDB里的数据库.
现在让我们来创建一个! 我们想要存储我们最喜欢的音乐专辑并富有创造性的把我们的数据库起名叫albums. 注意, 我们又一次使用了-X这个选项来告诉curl来发送一个PUT请求而不是默认的GET请求.
curl -X PUT http://127.0.0.1:5984/albums
CouchDB回应:
{“ok”:true}
That’s it. You created a database and CouchDB told you that all went well. What happens if you try to create a database that already exists? Let’s try to create that database again:
就是这样. 你创建了一个数据库然后CouchDB告诉你一切正常. 如果你试图创建一个已经存在的数据库会发生什么事? 我们来试试再创建同一个数据库:
curl -X PUT http://127.0.0.1:5984/albums
CouchDB回应:
{“error”:”file_exists”,”reason”:”The database could not be created, the file already exists.”}
我们得到了一个错误. 这相当方便. 我们同时学到了一点点关于CouchDB是如何工作的. CouchDB在一个单一文件里存储一个数据库. 非常简单. This has some consequences down the road, but we skip on details for now and explore the underlying storage system the The Power of B-Trees appendix.
让我们来创建另一个数据库, 这次带上curl的-v(“verbose”的简写)选项. verbose这个选项告诉curl不仅只显示必要的信息—HTTP的回复体, 还要显示请求与回复的细节:
curl -vX PUT http://127.0.0.1:5984/albums-backup
curl 详细显示:
* About to connect() to 127.0.0.1 port 5984 (#0)
* Trying 127.0.0.1… connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
> PUT /albums-backup HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Host: 127.0.0.1:5984
> Accept: */*
>
< HTTP/1.1 201 Created
< Server: CouchDB/0.9.0 (Erlang OTP/R12B)
< Date: Sun, 05 Jul 2009 22:48:28 GMT
< Content-Type: text/plain;charset=utf-8
< Content-Length: 12
< Cache-Control: must-revalidate
<
{"ok":true}
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
满满的一屏幕. 让我们一行行的看看来搞明白具体是在做什么并且找出哪些是重要的. 当你看过几次这个输出后, 你会更加容易的找出重要的部分.
* About to connect() to 127.0.0.1 port 5984 (#0)
这是curl在告诉我们正在向我们请求URI中的CouchDB服务器建立一个TCP连接. 没什么重要的地方, 只在调试网络问题的时候有用.
* Trying 127.0.0.1… connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
curl 告诉我们成功的连接到了CouchDB. 再一次, 不重要, 如果你没有发现什么网络问题的话.
下面的几行有一个”>”或者”<"的前缀. ">“的意思是这几行被逐字发送到CouchDB(不包括”>”). “<"的意思是这些是CouchDB发送回给curl的.
> PUT /albums-backup HTTP/1.1
这行初始化一个HTTP请求. 它的方法是PUT, URI是 /albums-backup, HTTP版本是HTTP/1.1. 还有一个HTTP/1.0的版本, 它在某些情况下更简单, 但是因为各种现实原因, 我们应该使用HTTP/1.1.
接下来, 我们看到一些请求头. 这些是用来提供到CouchDB的请求的附加细节的.
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
User-Agent头告诉CouchDB哪种客户端软件在作HTTP请求. 我们没有了解到什么新的, 就是curl. 在web开发中这个头经常很有用, 当知道服务器响应这个客户端实现的请求时存在问题时. 它也可以帮助决定, 用户是在哪个平台上的. 这个信息可以被用于技术和统计. 对于CouchDB来说, 这个头是无关的.
> Host: 127.0.0.1:5984
这个头是HTTP1.1需要的, 它告诉服务器请求的主机名.
> Accept: */*
Accept头告诉CouchDB, curl接受任何媒体类型. 我们会在后面来深入了解为什么这很有用.
>
一个空行表示请求头已经结束了, 剩下的请求包含我们要发送给数据库的数据. 在这个例子里, 我们不发送任何数据, 所以剩下的curl输出是HTTP响应的了.
< HTTP/1.1 201 Created
CouchDB的HTTP响应的第一行包含了HTTP版本信息(也让我们知道了, 请求的版本可以被处理). 一个HTTP状态码和一个状态码信息. 不同的请求会触发不同的返回状态码. 有一整个范围的状态码来告诉客户端(这个例子里是curl), 它作出的请求在服务器上做了什么. 或者如果有错误发生了, 告诉客户端什么错误发生了. RFC 2612, the HTTP 1.1 specification 清楚了定义了返回状态码的行为. CouchDB完全遵守这个RFC.
“201 Created”状态码告诉客户端请求要求创建的资源被成功的创建了. 没有什么值得惊奇的事, 但如果你还记得当我们试图两个创建这个数据库时我们得到了一个错误, 你就明白会有一个不同的返回码. 根据返回码做出处理是一个常见的做法. 比如, 所以400或400以上的返回码告诉你有什么错误发生了. 如果你想要简化你的逻辑并立即处理错误, 你可以只检查大于400的返回码.
< Server: CouchDB/0.9.0 (Erlang OTP/R12B)
Server头对于诊断很有用, 它告诉我们你是再和哪个版本的CouchDB和底层的哪个版本的Erlang打交道. 通常来说, 你可以忽略这个头, 但当你需要它的时候, 知道它在哪里也是好的.
< Date: Sun, 05 Jul 2009 22:48:28 GMT
Date头告诉你服务器的时间. 因为客户端和服务器端的时间没有必要一定同步, 这是头只是一个纯粹的信息而已. 你不应该根据这个信息为逻辑构建任何关键应用.
< Content-Type: text/plain;charset=utf-8
这个头告诉你HTTP响应体是什么原类型的和它的编码. 我们已经知道CouchDB返回JSON字符串. 合适的Content-Type是application/json. 为什么我们看到的是text/plain? 这是实用主义赢纯粹主义的地方. 发送一个applicaion/json的Content-Type头会使浏览器把返回的JSON提供给你下载而不是显示它. 因为可以在浏览器里测试CouchDB非常重要, CouchDB发送了一个text/plain的Content-Type, 这样浏览器就把JSON以文本的形式显示出来.
有一些浏览器插件可以让你的浏览器认得出JSON, 但是它们并不是默认安装的.
你还记得Accept请求头并且它是如何设置成”*/*”来表示它接受任何的源类型的吗? 如果你在你的请求里发送Accept: application/json, CouchDB认为你可以处理纯JSON响应, 会返回正确的Conten-Type头, 而不是text/plain.
< Content-Length: 12
这仅仅告诉我们响应体有多少字节.
< Cache-Control: must-revalidate
这告诉你或者任何在CouchDB和你之间的代理服务器不要缓存这个响应.
<
这个空行告诉我们响应头已经完了, 接下来的是响应体了.
{“ok”:true}
我们以前已经看到过这个了.
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
最后两行是curl告诉我们它会保持TCP连接打开一会, 但是在接收完整个响应后关掉它.
贯穿于整本书, 我们会展示更多的带-v选项的请求, 但是忽略掉一些我们已经在这里看过的头, 并只包含那些对于那个特定请求来说重要的.
我们已经知道如何创建数据库了, 但是如何删除一个呢? 简单, 只要改变HTTP方法.
curl -vX DELETE http://127.0.0.1:5984/albums-backup
这会删除一个CouchDB数据库. 这个请求会存储数据库内容的文件. 删除数据库时, 没有”你确定吗”安全保障或者”清空垃圾箱”之类的魔法. 谨慎的使用这个命令. 你的数据会被删除, 并且如果你没有做备份, 就没有任何机会再轻易的来回来了.
这部分深入的讲解了HTTP并且为讲解剩下的CouchDB API搭建了舞台. 下一站: 文档.
文档
文档是CouchDB的中心数据结构. 文档背后的观念是, 没有什么令人惊奇的, 就是真实世界的文档. 像帐单, 发票或者名片一样的一张纸片. 我们已经知道了, CouchDB使用JSON格式存储文档. 让我们看看这种存储是底层是如何工作的.
CouchDB里的每个文档都会一个id. 每个数据库里这个id都是唯一的. 你可以选择任何字符串作为id, 但是最好的, 我们推荐使用UUID(或者GUID). Universally (or Globally) Unique IDentifier. UUID是一些极小可能重复的数字, 以至于每个人以每分钟产生成千上万个UUID的速度过几百万年都不会有重复产生. 这是一种非常棒的方法来保证两个独立的人不会产生有相同id的文档. 为什么你要关心其他人在干什么? 第一个原因, 那个”其他人”可能会是以后某个时间某台不同电脑上的你自己; 第二个原因, CouchDB备份让你使用UUID来和其他人分享文档, 用UUID可以保证它工作正常. 呆会我们再详细解释, 现在来创建几个文档.
curl -X PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af -d ‘{“title”:”There is Nothing Left to Lose”,”artist”:”Foo Fighters”}’
CouchDB响应:
{“ok”:true,”id”:”6e1295ed6c29495e54cc05947f18c8af”,”rev”:”1-2902191555″}
这个curl命令看起来有些复杂, 我们来分解一下. 首先 -X PUT 告诉curl作一个PUT请求. 它后面跟着一个URL来指定你的CouchDB的IP地址和端口. URL的资源部分 /albums/6e1295ed6c29495e54cc05947f18c8af 指定了我们的albums数据库中文档的位置. 那串乱七八糟的数字和字母集合是一个UUID. 这个UUID是你的文档的id. 最后, -d 标志告诉 curl 用后面跟着的字符串来做PUT请求的body. 这个字符串是一个简单的JSON结构, 包括了标题和艺术家属性以及它们相应的值.
如果你手头上没有UUID, 你可以让CouchDB给你一个(实际上, 这正是我们刚才做的, 只不过没有向你展示出来). 仅仅需要发送一个GET请求到 /_uuids.
curl -X GET http://127.0.0.1:5984/_uuids
CouchDB响应:
{“uuids”:["6e1295ed6c29495e54cc05947f18c8af"]}
如果你需要多于一个的UUID, 你可以传入 ?count=10 的HTTP参数来请求10个UUID, 或者任何你想要的数字.
为了确认CouchDB是不是在对你撒谎说它已经保存了你的文档(通常它不会:), 试着用一个GET请求来得到它.
curl -X GET http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af
我们希望你能看出一种模式. CouchDB里的一切东西都有一个地址, 一个URI; 你使用不同的HTTP方法来操作这些URI.
CouchDB响应:
{“_id”:”6e1295ed6c29495e54cc05947f18c8af”,”_rev”:”1-2902191555″,”title”:”There is Nothing Left to Lose”,”artist”:”Foo Fighters”}
这和你要CouchDB保存的文档很相似, 很好. 但是你应该注意到了, CouchDB在JSON结构中加了两个域. 第一个是_id, 它的值是我们叫CouchDB保存的文档的UUID. 如果有包含文档的id的话, 我们也在这里得到了, 这很方便.
第二个是_rev. 它代表版本号.
版本
如果你想CouchDB里的一个文档, 你不是告诉它去找到特定文档中的一个域然后插入一个新值. 而是从CouchDB载入整个文档, 在JSON结构里作改变(或者是一个对象, 当你使用某个编程语言时), 然后把整个新版本的文档存回CouchDB. 每个版本由一个新的_rev值标识.
如果你想要更新或者删除一个文档, CouchDB会期望你会提供一个_rev域来标识你要改变哪个版本. 当CouchDB接受了一个更改以后, 它会产生一个新的版本号. 这种机制保证了, 万一有人在你对文档做更新之前做了一个你不知道的更新, CouchDB不会接受你的更新因为你可能会覆盖你以为不存在的数据. 或者简单点的说: 谁先保存了对一个文档的改变, 谁就赢了. 让我们来看看如果我们不提供一个_rev域会发生什么(这和提供一个过时的值是一样的).
curl -X PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af -d ‘{“title”:”There is Nothing Left to Lose”,”artist”:”Foo Fighters”,”year”:”1997″}’
CouchDB响应:
{“error”:”conflict”,”reason”:”Document update conflict.”}
如果你看到了这个, 在JSON结构里加上你的文档的最新版本号:
curl -X PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af -d ‘{“_rev”:”1-2902191555″,”title”:”There is Nothing Left to Lose”,”artist”:”Foo Fighters”,”year”:”1997″}’
现在你会发现为什么在你作了这个请求后, CouchDB返回_rev会是件很方便的事.
CouchDB响应:
{“ok”:true,”id”:”6e1295ed6c29495e54cc05947f18c8af”,”rev”:”2-2739352689″}
CouchDB接受了你的写请求并且它也产生了一个新的版本号. 版本号是文档的md5散列, 加上一个N-的前缀表示文档被更新的次数. 这对备份很有用. 具体看冲突管理章节.
There are multiple reasons why CouchDB uses this revision system that is also called Multi Version Concurrency Control (MVCC). They all work hand-in-hand and this is a good opportunity to explain some of them.
为什么CouchDB使用这种版本系统, 也被叫作多版本并发控制(MVCC), 有多个原因.
CouchDB使用的其中一个HTTP协议的特性是它的无状态性. 这是什么意思? 要和CouchDB交流, 你需要做出请求. 做一个请求包括了打开一个到CouchDB的网络连接, 交换字节然后关闭连接. 这些你每做一个请求都会重复一遍. 另外的协议允许你打开一个连接, 交换字节, 保持这个连接打开, 然后在此后交换更多的字节, 也许是根据你一开始交换字节里包含的内容, 最后关闭连接. 保持一个连接用于今后使用要求服务器作额外的工作. 一个常见的模式是, 在一个连接的生命周期里, 客户端有一个持久的, 静态的服务器的数据视图. 管理巨大量的并行的连接是一项极大工作量的活. HTTP连接通常是短生命周期的, 作出同样的保障会轻松很多. 结果就是, CouchDB可以处理更多的并发连接.
另外一个原因是这个模型在概念上更简单, 因此更加容易编程. CouchDB使用了更少的代码来达到目标, 而使用更少的代码总是好事, 因为固定行数代码的缺陷比例是固定的.
版本系统对于备份和存储机制也有积极的作用, 但我们将在本书的后面章节来讲到它们.
文档的细节方面
Now let’s have a closer look at our document creation requests with the curl -v-flag that was helpful when we explored the database API earlier. This is also a good opportunity to create more documents that we can use in later examples.
现在让我们用 curl 的 -v 标志来近距离的看看我们的文档创建请求, 这在之前我们探索数据库API的时候很有用. 这也是一个创建更多文档的好机会, 以便我们在今后的例子中使用.
我们会增加一些我们最喜欢的音乐专辑. 从 /_uuids 资源得到一个新的UUID. 如果你不记得这是怎么做了, 把书翻回去几页找找.
curl -vX PUT http://127.0.0.1:5984/albums/70b50bfa0a4b3aed1f8aff9e92dc16a0 -d ‘{“title”:”Blackened Sky”,”artist”:”Biffy Clyro”,”year”:2002}’
顺便提一下, 如果你正好知道更多的关于你最喜爱专辑的信息的话, 不要犹豫添加上这些属性. 也不要着急如果你不知道所有这些专辑的所有信息, CouchDB的无模式文档可以包含任何你知道的. 总之, 你应该放松, 不要去担心数据.
带着-v选项, CouchDB响应的重要部分看起来应该像是这样:
> PUT /albums/70b50bfa0a4b3aed1f8aff9e92dc16a0 HTTP/1.1
>
< HTTP/1.1 201 Created
< Location: http://127.0.0.1:5984/albums/70b50bfa0a4b3aed1f8aff9e92dc16a0
< Etag: "1-2248288203"
<
{"ok":true,"id":"70b50bfa0a4b3aed1f8aff9e92dc16a0","rev":"1-2248288203"}
在返回头中, 我们得到了一个201″创建” HTTP状态码, 这在之前我们创建数据库时我们也见过了. Location头告诉我们最新创建文档的完整URL. 而且有一个新的头; 来看看Etag先生. 在HTTP里, 一个Etag标识了一个资源的特定版本. 在这个例子里, 它标识了我们的新文档的一个特定版本. 听起来很熟悉? 是的, 从概念上讲, 一个Etag就是CouchDB文档的一个版本号, 所以CouchDB使用版本号作为Etag也没有什么可以惊讶的了. Etag在缓存系统中很有用, 我们会在第五部分, 扩展CouchDB中学会如何使用.
附件
CouchDB documents can have attachments just like an email message can have attachments. An attachment is identified by a name and includes its mime type (or content type) and the number of bytes the attachment contains. Attachments can be any data. It is easiest to think about attachments as files attached to a document. These files can be text, images, Word documents, music or movie files. Let’s make one.
CouchDB文档可以有附件, 就像email可以带附件一样. 一个附件由一个名字和它的mine类型(或者content类型)以及它的字节数来标识. 附件可以是任何数据. 最简单的理解是附件就是附加在文档上的文件. 这些文件可以是文本, 图像, Word文档, 音乐或者电影文档. 让我们来创建一个.
附件有它们自己的URL, 你可以把数据上传到那. 假设我们想要把一张专辑的封面添加到文档6e1295ed6c29495e54cc05947f18c8af, 并且假设封面文档是当前目录下的artwork.jpg.
> curl -vX PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af/artwork.jpg?rev=2-2739352689 –data-binary @artwork.jpg -H “Content-Type: image/jpg”
-d@ 选项告诉 curl 去读取文档的内容放到HTTP请求体. 我们使用-H选项告诉CouchDB我们上传的是一个JPG文件. CouchDB会保存这个信息并且当我们请求这个文档的时候, 返回合适的头; 比如像这样的一个图像, 一个浏览器会显示这个图像而不会要你下载这个数据. 这在今后会变得很方便. 注意, 你需要提供你想到附加到的文档的当前版本号, 就和你更新一个文档时一样. 因为, 不管怎么样, 附加一些数据也是在改变这个文档.
如果你把你的浏览器指向`http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af/artwork.jpg `, 你应该会看到你的封面图片.
如果你再一次请求文档, 你会看到一个新的成员 _attachments:
curl http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af
CouchDB响应:
{“_id”:”6e1295ed6c29495e54cc05947f18c8af”,”_rev”:”3-131533518″,”title”:”There is Nothing Left to Lose”,”artist”:”Foo Fighters”,”year”:”1997″,”_attachments”:{“artwork.jpg”:{“stub”:true,”content_type”:”image/jpg”,”length”:52450}}}
_attachments是一个key和value的列表, value是包含附件原数据JSON对象. stub=true告诉我们, 这个附件只是一个原数据. 如果我们在请求一个文档时, 使用 ?attachments=true这个HTTP选项, 我们会得到一个包含附件数据的base64编码数据.
在我们探索CouchDB特性时, 会看到更多的文档请求选项. 比如备份, 我们的下一个主题.
备份
CouchDB备份是一个用于同步数据库的机制. 很像rsync(如果你熟悉这个的话)在本地或者网络上同步两个目录, 备份在本地或者远程同步两个数据库.
在一个简单的POST请求里, 你告诉CouchDB备份的源和目标, 然后CouchDB会在源上找出有哪些文档和哪些新文档版本是目标上没有的并且会把它们移到目标上.
我们会在本书的后面深入的探索备份;在本章节中, 我们只是向你展示如何使用它.
首先, 我们创建一个目标数据库. 注意, CouchDB不会自动的为你创建一个目标数据库而是会返回一个备份失败, 如果目标不存在的话(少了源的话也一样, 不过这个错误很不容易犯:).
curl -X PUT http://127.0.0.1:5984/albums-replica
现在我们可以使用数据库album-replica作为一个备份目标:
curl -vX POST http://127.0.0.1:5984/_replicate -d ‘{“source”:”albums”,”target”:”albums-replica”}’
CouchDB响应(这次我们对输出做了格式化, 这样你可以更加简单的读它):
{
“history”: [
{
"start_last_seq": 0,
"missing_found": 2,
"docs_read": 2,
"end_last_seq": 5,
"missing_checked": 2,
"docs_written": 2,
"doc_write_failures": 0,
"end_time": "Sat, 11 Jul 2009 17:36:21 GMT",
"start_time": "Sat, 11 Jul 2009 17:36:20 GMT"
}
],
“source_last_seq”: 5,
“session_id”: “924e75e914392343de89c99d29d06671″,
“ok”: true
}
CouchDB会维护一份备份的历史. 一个备份请求的回应会包含这个备份的历史备份. 备份请求会一直保持打开直到备份结束. 如果你有很多的文档, 这会花点时间, 直到它们都被备份了, 而且直到它们都被备份了, 你不会得到备份的响应. 有一点很重要的需要注意的是, 备份, 只会备份开始备份时的数据库的那个点. 所以, 任何在备份开始后的添加, 更改或者删除不会被备份.
We’ll punt on the details again, 最后的”ok”:true告诉我们一切顺利. 如果现在你看下albums-replica数据库, 你应该会看到所有你在albums数据库创建的文档.
你刚才所作的在CouchDB的术语里叫做本地备份. 你创建了一个本地的数据库的副本. 这对于备份, 或者保留一份数据在某个特定时间的快照以便日后使用来说是很有用的. 如果你在开发一个应用, 但是想在需要的时候可以返回到稳定的代码和数据版本, 你可能会想要做备份.
还有其他种类的复制, 在其他状况下有用. 我们备份的源和目标实际上是链接(就像在HTML里的那种), 而到目前为止, 我们看到的链接是指向我们正在工作的(就是本地的). 你也可以指定一个远程数据库作为目标:
curl -vX POST http://127.0.0.1:5984/_replicate -d ‘{“source”:”albums”,”target”:”http://127.0.0.1:5984/albums-replica”}’
使用一个本地源和一个远程目标数据库被叫做push replication. 我们把改变推到远程服务器.
想和远程服务器或者对门的家伙共享数据, 这方法好极了.
你也可以使用一个远程源和一个本地目标做pull replication. 想要拿到别人数据库上作的最新改变, 这也是个好办法.
curl -vX POST http://127.0.0.1:5984/_replicate -d ‘{“source”:”http://127.0.0.1:5984/albums-replica”,”target”:”albums”}’
最后, 你可以作远程备份, 这在管理操作时比较有用:
curl -vX POST http://127.0.0.1:5984/_replicate -d ‘{“source”:”http://127.0.0.1:5984/albums”,”target”:”http://127.0.0.1:5984/albums-replica”}’
收尾
这仍然不是完整的CouchDB API, 但是我们仔细的讨论了必要的部分. 我们将边走边把剩下的空白填上. 现在我相仿你已经准备构建CouchDB应用了.
