[
https://issues.apache.org/jira/browse/CASSANDRA-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165276#comment-14165276
]
Sylvain Lebresne commented on CASSANDRA-7970:
---------------------------------------------
I'll note that there is imo 2 slightly separate case to handle. Not only do we
want to translate full JSON objects to CQL rows and vice-versa as in the
example of the description. But we should also allow to convert CQL values to
JSON and vice-versa, because well, the row to/from json will really just be a
little extension of the cql value to/from json. Concretely, we'd want something
along the lines of:
{noformat}
UPDATE users SET addresses = addresses + fromJson($${"work" : { ... }}$$) WHERE
id = ...
{noformat}
and I don't see why we wouldn't allow stuffs like:
{noformat}
SELECT id, toJson(addresses) FROM users;
{noformat}
since again, we will have to implement such functions internally. For those
cases, I do think the "functional" syntax work better than a specific syntax
because well, those are really plain old functions.
That said, I'd be personally be fine with adding toJson/fromJson functions for
the conversion of CQL value to and from json, but having specific syntax like
the one in the description to apply the conversion to full rows (I do agree
that the "functional" syntax is somewhat inconsistent with normal functions
when it comes to applying it to row).
> JSON support for CQL
> --------------------
>
> Key: CASSANDRA-7970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7970
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Jonathan Ellis
> Assignee: Tyler Hobbs
> Fix For: 3.0
>
>
> 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)
