asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: "Clean JSON" proposal
Date Fri, 11 Sep 2015 13:58:08 GMT
Very nice!!  I would be inclined to switch the default, yes.  Then for ADM
it would be cool to have two options as well, one "wrapped" and one
"unwrapped" (the latter being the default, and not having the outermost [
]).
On Sep 11, 2015 2:14 AM, "Chris Hillery" <chillery@hillery.land> wrote:

> The current proposed "clean JSON" solution works as follows:
>
> You still request JSON output from the HTTP API via the Accept: HTTP header
> or via a "output" CGI query parameter, and the default output format from
> the HTTP API is still JSON.
>
> If you do nothing, you will get the same lossless JSON that we have
> provided for some time. However I have now added a parameter "clean", which
> if set to the value "true", selects the new "clean JSON" output. You can
> specify this parameter either via a CGI parameter or via a parameter on the
> MIME type specified via the Accept: HTTP header (ie., "Accept: text/csv;
> clean=true"). This is directly parallel to the ways you can request a
> header line when selecting CSV output.
>
> *Question #1: *Should "clean JSON" be the new default? If so I would
> introduce a "lossless=true" parameter for selecting the old format.
>
> *Question #2:* Is this parameter-based approach (using the same output
> format for both kinds of JSON) OK? Or should we invent a different MIME
> type to represent one of them in the Accept: header? (I think probably the
> resulting Content-Type: header in the response should be text/json in
> either case, however.)
>
> As for the actual content of clean JSON, I went with all the
> non-controversial choices for numerics, strings, boolean, records, and
> ordered/unordered lists. I went with what I believe are non-controversial
> choices for UUID, binary, and date/time types (the obvious string
> representations in all cases). Finally, for the controversial spatial
> types, I went with the simplest representation: simple arrays of numbers.
> This jibed with Mike's last comments on the lengthy thread a few weeks ago
> and with my own feelings on the matter. It also seemed like the least work,
> which is relevant since it also seems like we may need to change our
> spatial support anyway.
>
> You can see a hopefully self-describing example of all types in the result
> of the test case I added:
>
> https://asterix-gerrit.ics.uci.edu/#/c/362/4/asterix-app/src/test/resources/runtimets/results/scan/alltypes_01-cleanjson/alltypes_01.1.json
>
> *Quesiton #3: *Anyone want to make a last-ditch proposal for something
> different for spatials?
>
> Anyway, these changes are ready for review; have been for a couple weeks,
> in fact.
>
> Ceej
> aka Chris Hillery
>

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