You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Chris Hillery <ch...@hillery.land> on 2015/09/11 11:14:25 UTC
"Clean JSON" proposal
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
Re: "Clean JSON" proposal
Posted by Mike Carey <dt...@gmail.com>.
PS-Formatting wise, where are we now on CSV in and out and header
handling? (And round tripping?)
On Sep 11, 2015 6:58 AM, "Mike Carey" <dt...@gmail.com> wrote:
> 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" <ch...@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
>>
>
Re: "Clean JSON" proposal
Posted by Mike Carey <dt...@gmail.com>.
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" <ch...@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
>