That's good news, but couchdb should remove this ambiguity. Perhaps the quickest thing is to add a "follows_order":[] in the json blob which, since the value is an array, can be unambiguously evaluated.
I'm keener on this idea, though: the JSON blob in a multipart/related PUT does not need to mention new attachments at all (though it does need stubs to preserve existing attachments). All non-first parts are explicitly intended to be added to the document. Those parts can have standard headers that tell us the attachments name and expected length. The further proposal, mentioned at the Boston Summit, would remove all the magical _-prefix values from the document, which would motivate us to unpick this tangle even more completely. B. On 8 Aug 2012, at 18:26, Jens Alfke wrote: > Robert, > >> Having read much of the attachment streaming code and the multipart parsing >> code, and the manner that they connect, the fix isn't going to be easy but >> it feels necessary. >> Each MP part can have http headers, including Content-Length, which points >> to a way forward. > > Great. Actually the workaround on my side is going to be easier than I > thought, because I just realized I've already written a custom JSON encoder, > for the purpose of generating canonical JSON (necessary for getting > consistent revision IDs for the same document bodies.) And a big part of what > that encoder does is write dictionary keys in sorted order. So I can use that > to write the main document body, and then make sure to write the attachment > bodies sorted in the same order by filename. (Pieter, I think I can have this > pushed out pretty soon, probably later today.) > > —Jens >
