[
https://issues.apache.org/jira/browse/CASSANDRA-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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|https://github.com/thobbs/cassandra/tree/7970-trunk-v2].
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|https://github.com/thobbs/cassandra/commit/fab555234f7c5d9e7c617037fd7d7b220b9f776d],
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: https://issues.apache.org/jira/browse/CASSANDRA-7970
> 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>
> );
> INSERT INTO users JSON
> {‘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] http://rustyrazorblade.com/2014/07/the-myth-of-schema-less/
> [2] https://blog.compose.io/schema-less-is-usually-a-lie/
> [3] http://dl.acm.org/citation.cfm?id=2481247
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
