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 <[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?
