asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <>
Subject Re: json vs. JSON
Date Wed, 05 Aug 2015 07:05:00 GMT
Cool.  Sattam + Wail are going to sign up to do this, I believe!   (They 
want/need it first....)

On 8/1/15 9:38 AM, Till Westmann wrote:
> Only a few thoughts:
> 1) Yes, we should definitely have that!
> 2) For the non-numeric extended atomic types we should find a reasonable string serialization
and we need to provide functions to parse that serialization back to the extended atomic type
(and I think that we already have that e.g. for the datetime types).
> 3) I think that we already had that discussion a few times (I remember arguing for it
when I first joined the project) and it’s time to do it :)
> Cheers,
> Till
>> On Aug 1, 2015, at 9:17 AM, Mike Carey <> wrote:
>> Hey - our JSON output format is currently designed to be non-lossy, in the sense
that it encodes all the details of the source types (since ADM is JSON++ and there's quite
a bit in that ++ section).  We really also need an option for "normal application users" that's
lossy but produces the kind of JSON that would be expected by consuming applications that
"don't appreciate" the many different kinds of numeric data, the existence of spatial data,
etc.  I.e., it'd be nice to have a default lossy serialization into JSON as well....  (Note
that if someone doesn't want to suffer the loss, they can always do their own out-conversions
of the data in the return section of their AQL query to bridge the gap.)  Thoughts?

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