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 <[email protected]> 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?
