On Thu, Feb 26, 2009 at 8:42 AM, Jeff Hinrichs - DM&T <dunde...@gmail.com> wrote: > On Thu, Feb 26, 2009 at 3:56 AM, Jan Lehnardt <j...@apache.org> wrote: >> >> On 26 Feb 2009, at 09:03, Brian Candler wrote: >> >>> On Wed, Feb 25, 2009 at 07:07:11AM -0600, Jeff Hinrichs - DM&T wrote: >>>>> >>>>> CouchDB dodges this at present, since you can't download a document >>>>> together >>>>> with its attachments. >>>> >>>> what about ?attachments=true or am I misunderstanding you? >>> >>> This is new to me - such feature doesn't seem to be mentioned at >>> http://wiki.apache.org/couchdb/HTTP_Document_API, where it says: >>> >>> "When retrieving documents, the attachment's actual data is not included, >>> only the metadata. The actual data has to be fetched separately, using a >>> special URI." >>> >>> However I do see "attachments=true" in couch_rep.erl. Is this something >>> internal/private for replication? >> >> This is an omission in the documentation. I added it to the wiki now with >> a note that you should not use it :) I think the plan forward is to add an >> API >> where documents and attachments can be transferred in a single HTTP >> request using a multipart mime request. This will speed up replication, > Not immediately apparent that this is true, only if mime encode/decode > is faster than json encode/decode >
The major speed up factors when doing this in multipart mime are: 1. Streaming bytes from and to disk for attachments. 2. No Base64 round trip 3. No base64 means less data transferred Seems like I'm missing another one, but those are the biggies. HTH, Paul Davis >> fix handling replication with large attachments and makes it possible to >> create a document and a set of attachments without going through >> intermediate revisions. > I am doing this currently, the recent fix to mochiweb of the 1MB body > regression allows one to upload document + attachments in a single > revision -- you need to base64 the attachment and set the attributes, > but it works. My dump/load code does it quite nicely. >> > > Regards, > > Jeff Hinrichs >
