所以我一直在搞乱气垫船并遇到一些恼人的限制，这可能是因为内部couchdb处理与文档关联的键/值对作为不透明字符串（json字符串）。
namelly：
- doc _id只能是二进制字符串（utf8） - 这里不允许复杂的erlang术语
- 键/值对只能是binatry_strings或原子或列表（不允许使用元组或任意二进制文件）。
我期待在那里存储任意的erlang术语，而不是首先将它们编码为JSON。是的，这是可能的，但随后整个视图系统（以及http api，通知，验证，索引）才停止工作。
这也很好，我可以围绕它编码，不使用蒲团，手动映射/减少文档并将结果存储为文档（实际上更好，因为那时结果可以复制到其他数据库/节点，不像视图结果（不是复制 - 纠正我，如果我错了））。
真正的问题似乎是没有视图就无法获得存储在数据库中的所有密钥的列表，至少不能通过当前的气垫船api获得。这是在整个数据库上手动mapreducing的show stoper，而不知道doc _id是什么。
关于如何在数据库中获取这些密钥列表的任何想法？通过erlang调用，可能进入couchdb的内部？
现在对我来说更加明显的是，对于couchdb的直接erlang api是完整的。
答案 0 :(得分：2)
作为Hovercraft的作者，我同意声明“对于couchdb的直接erlang api是完全的。”
如果要将CouchDB从HTTP服务器转换为SMTP服务器，则只应使用Hovercraft。 HTTP将比Hovercraft更好地扩展。
应该可以使用内部_changes API迭代数据库中的所有文档并逐步维护二级索引。
至于在CouchDB中存储非JSON数据，这听起来很冒险，因为没有人会注意确保我们不会破坏您的用例。
但如果你玩得开心，请继续。而且我喜欢在气垫船上获得补丁，所以任何小东西都可能会被卷回来。
谢谢， 克里斯