cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-7970) JSON support for CQL
Date Tue, 20 Jan 2015 23:30:37 GMT


Tyler Hobbs updated CASSANDRA-7970:
    Attachment: 7970-trunk-v1.txt

7970-trunk-v1.txt is a first stab at this.  I also have a [branch|].

Some notes on the implementation:
* {{toJson()}} can only be used in the selection clause of a {{SELECT}} statement, because
it can accept any type and the exact argument type must be known.
* {{fromJson()}} can only be used in {{INSERT}}/{{UPDATE}}/{{DELETE}} statements because the
receiving type must be known in order to parse the JSON correctly.
* As discussed, ints, floats, and booleans can be also be represented by strings.
* I attempted to improve the handling of collection serialization formats by switching from
directly using the protocol version to using an enum with two values: PRE_V3 and V3.  I have
mixed feelings about the results.  It does replace some confusing usages of the protocol version
and a few magic numbers, but I'm not sure it's worth it.  These changes are contained by a
[single commit|],
so I can undo that easily if we want.
* To simplify internal handling of a single query parameter for {{INSERT JSON}}, a single
{{Json.AllValues}} object is shared by multiple {{Json.Value}} objects which simply grab the
value for a specific column from the {{AllValues}} object.
* Case sensitivity in {{INSERT JSON}} is somewhat awkward.  I decided to try to match Cassandra's
normal behavior.  Map keys are case-insensitive by default, but you can add quotes within
the string to make them case-sensitive.  {{SELECT JSON}} matches this behavior by adding quotes
to keys whenever they contain uppercase characters.

> JSON support for CQL
> --------------------
>                 Key: CASSANDRA-7970
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API
>            Reporter: Jonathan Ellis
>            Assignee: Tyler Hobbs
>             Fix For: 3.0
>         Attachments: 7970-trunk-v1.txt
> JSON is popular enough that not supporting it is becoming a competitive weakness.  We
can add JSON support in a way that is compatible with our performance goals by *mapping* JSON
to an existing schema: one JSON documents maps to one CQL row.
> Thus, it is NOT a goal to support schemaless documents, which is a misfeature [1] [2]
[3].  Rather, it is to allow a convenient way to easily turn a JSON document from a service
or a user into a CQL row, with all the validation that entails.
> Since we are not looking to support schemaless documents, we will not be adding a JSON
data type (CASSANDRA-6833) a la postgresql.  Rather, we will map the JSON to UDT, collections,
and primitive CQL types.
> Here's how this might look:
> {code}
> CREATE TYPE address (
>   street text,
>   city text,
>   zip_code int,
>   phones set<text>
> );
> CREATE TABLE users (
>   id uuid PRIMARY KEY,
>   name text,
>   addresses map<text, address>
> );
> {‘id’: 4b856557-7153,
>    ‘name’: ‘jbellis’,
>    ‘address’: {“home”: {“street”: “123 Cassandra Dr”,
>                         “city”: “Austin”,
>                         “zip_code”: 78747,
>                         “phones”: [2101234567]}}};
> SELECT JSON id, address FROM users;
> {code}
> (We would also want to_json and from_json functions to allow mapping a single column's
worth of data.  These would not require extra syntax.)
> [1]
> [2]
> [3]

This message was sent by Atlassian JIRA

View raw message