couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bradford Winfrey <>
Subject Re: File Attachments
Date Thu, 03 Jul 2008 13:29:20 GMT

Check this page of the Wiki out - down a bit (I'd just search for Attachments)

As far as I know, yes you do need to base64-encode them and then push them on up to CouchDB.

Hope this helps,

----- Original Message ----
From: Jeff Hinrichs - DM&T <>
Sent: Thursday, July 3, 2008 8:13:03 AM
Subject: File Attachments

Can someone point me to the wiki or discussion about how to handle
documents with attached file(s)?  I see references to the subject in
various places but have yet to find the "couchdb" way of doing it.

Do I just base64 encode the file contents and save that along with
filetype and other name attrs in a couchdb document?  Or is it
preferred to mime-encode like cmlenz does with the dump/load scripts?

I see in the wiki under UriTemplates, the method to download a file
attachment, but that would seem to infer that there is a correct way
to attach a file so that the method [WWW]
http://localhost:5984/dbname/docid/_bin/filename does the right thing.

Also, I've seen mention in the list of a 2GB limit to a database,
however I can't seem to find that in the docs -- is this limit
correct?  If it is, are there plans to expand the limit?

Finally, the idea I am toying with is using couchdb to store binary
documents with meta information.  Think of something like a blog, but
instead of the post content being text, it would be a binary document
(PDF, OO, etc), the comments would be other binary documents and their
associated meta data.  Is couchdb a non-optimal solution or would it
be a good solution?  The database would be rather large and constantly
growing -- if couchdb is a good fit, are there limits to database size
that would affect the architecture? partitioning, etc?

This wouldn't be a document revision control system, once an attached
file is stored it won't be changed, although amended documents would
be stored in the "comments" of the original post.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message