couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick North <nort...@gmail.com>
Subject Re: [jira] [Commented] (COUCHDB-1521) multipart parser gets multiple attachments mixed up
Date Fri, 10 Oct 2014 10:04:34 GMT
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) <jira@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)
>

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