My recollection of that bit of code is the same as Jan's: it processes in JSON order. I did start thinking about how to improve this behaviour at one point, but got stuck trying to work out something that is backwards-compatible. It's some while since I looked at it so I can't bring to mind exactly what the difficulty was.
Nick On 10 October 2014 10:57, Jan Lehnardt (JIRA) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14166604#comment-14166604 > ] > > Jan Lehnardt commented on COUCHDB-1521: > --------------------------------------- > > I think we still do the “process according to json order” bit, though. > > > multipart parser gets multiple attachments mixed up > > --------------------------------------------------- > > > > Key: COUCHDB-1521 > > URL: https://issues.apache.org/jira/browse/COUCHDB-1521 > > Project: CouchDB > > Issue Type: Bug > > Components: HTTP Interface > > Affects Versions: 1.2 > > Reporter: Jens Alfke > > Assignee: Randall Leeds > > > > When receiving a document PUT in multipart format, CouchDB gets the > attachments and MIME parts mixed up. Instead of looking at the headers of a > MIME part to identify which attachment it is (most likely by using the > 'filename' property of the 'Content-Disposition:' header), it processes the > attachments according to the order in which their metadata objects appear > in the JSON body's '_attachments:' object. > > The problem with this is that JSON objects (dictionaries) are _not_ > ordered collections. I know that Erlang's implementation of them (as linked > lists of key/value pairs) happens to be ordered, and I think some > JavaScript implementations have the side effect of preserving order; but in > many languages these are implemented as hash tables and genuinely unordered. > > This means that when a program written in such a language converts a > native object to JSON, it has no control over (and probably no knowledge > of) the order in which the keys of the JSON object are written out. This > makes it impossible to then write the attachments in the same order. > > The only workaround seems to be for the program to implement its own > custom JSON encoder just so that it can write object keys in a known order > (probably sorted), which then enables it to write the attachment bodies in > the same order. > > NOTE: This is the flip side of COUCHDB-1368 which I filed last year; > that bug has to do with the same ordering issue when CouchDB _generates_ > multipart responses (and presents similar problems for clients not written > in Erlang.) > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) >
