Return-Path: X-Original-To: apmail-zest-dev-archive@minotaur.apache.org Delivered-To: apmail-zest-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 931FE18E0B for ; Thu, 21 May 2015 08:37:38 +0000 (UTC) Received: (qmail 57863 invoked by uid 500); 21 May 2015 08:37:38 -0000 Delivered-To: apmail-zest-dev-archive@zest.apache.org Received: (qmail 57827 invoked by uid 500); 21 May 2015 08:37:38 -0000 Mailing-List: contact dev-help@zest.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@zest.apache.org Delivered-To: mailing list dev@zest.apache.org Received: (qmail 57815 invoked by uid 99); 21 May 2015 08:37:38 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 May 2015 08:37:38 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id AF966C11B9 for ; Thu, 21 May 2015 08:37:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id eV-HbR0BmNY4 for ; Thu, 21 May 2015 08:37:32 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id B414448487 for ; Thu, 21 May 2015 08:37:31 +0000 (UTC) Received: by iepj10 with SMTP id j10so3115101iep.3 for ; Thu, 21 May 2015 01:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=KkhrqsQCqsM215i/A4olAnGm0l0tMni8T69zfEPUUw8=; b=BuCV+Yt9H+wjhFdbFoBcniReFwhs746R35ZDtgjsfzmc0O9SPwiWyV5Ygjnn1A2gk0 Tg6iLoGAgxkHakuVd5FEMC8dCN6jS1/f9q+1hrVWbDqC9xWTEAjC0Jda0rC50mIoBjly /Q/QxrjSBS2NQiUrrg5zU9kpruuH4a8s2RZoLNeXmoCVGNlkWZT5rqWHGc8vKmrEbsDB vJPNd7voElYRtUU2+XB7khtYlo+Q0oOQXBlWppucsbyNA5Lyyo8WznLVkBg0l5Pvmqui atk0cAZV2Y82uhORN/EYAdbtOyOdwFa8I7tK0sy0RMvx1gkwScDjwKl+3ORzDH4lm24M wmlg== X-Received: by 10.107.163.79 with SMTP id m76mr1900043ioe.85.1432197451335; Thu, 21 May 2015 01:37:31 -0700 (PDT) MIME-Version: 1.0 Sender: hedhman@gmail.com Received: by 10.36.98.18 with HTTP; Thu, 21 May 2015 01:37:10 -0700 (PDT) In-Reply-To: References: From: Niclas Hedhman Date: Thu, 21 May 2015 16:37:10 +0800 X-Google-Sender-Auth: tT8pjyoaaMUTU9RatUwt13ZCOJw Message-ID: Subject: Re: ZEST-23 To: dev Content-Type: multipart/alternative; boundary=001a11402aca55cf9a05169374f5 --001a11402aca55cf9a05169374f5 Content-Type: text/plain; charset=UTF-8 I have been looking at this issue and I wonder if there are any notes from the original implementation... For instance, a regular Map is serialized to map: [ { "key" : "FirstName", "value" : "Niclas" }, { "key" : "LastName", "value" : "Hedhman" } ] but it could have been made; map : { "FirstName" : "Niclas", "LastName" : "Hedhman" } My guess is that there is "schema" reasons for this. Also, it is not something that can now be changed, at least not without adding built-in handing of old format (which is a possibility). One of the usecases of this outside of the storage, would be using this serialization SPI for the toValue() and toEntity() methods, in which case the serialization would end up being processable in JavaScript. So, in that case, would it makes more sense to have "key"/"value", or to have Maps showing up as objects?? I am not that fluent in JavaScript to have an opinion. I can imagine that having the second/object form, is neat when one knows what is coming over the wire, but could messy to iterate as built-in attributes need to be filtered out. Or? // Niclas On Thu, May 21, 2015 at 7:55 AM, Niclas Hedhman wrote: > Jiri, > thanks for your analysis of why it breaks. > > I assume that a JSON Object for NamedAssociation is the correct path > forward, > > { > "left" : "723470239476", > "right" : "109874275692" > } > > instead of the JSON Array which needs inner objects in that case, > > [ > { "left" : "723470239476" }, > { "right" : "109874275692" } > ] > > Paul, your thoughts? > > Cheers > -- > Niclas Hedhman, Software Developer > http://zest.apache.org - New Energy for Java > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java --001a11402aca55cf9a05169374f5--