[
https://issues.apache.org/jira/browse/CASSANDRA-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157097#comment-14157097
]
Tyler Hobbs commented on CASSANDRA-7970:
----------------------------------------
We had some discussion about implementing this as a function instead of a
syntax extension, I would like to document my thoughts on the two choices.
h3. Syntax Approach
Inserts:
{{INSERT INTO users (id, name, address) JSON $$\{'id': ...\}$$;}}
Selects:
{{SELECT JSON id, address FROM users;}}
or
{{SELECT id, address FROM users WITH JSON FORMATTING;}}
Possible future enhancements such as default values and transformation
functions can be handled with syntax:
* {{INSERT INTO users JSON ? WITH JSON DEFAULTS = \{<field>: <default>\}}}
* {{INSERT INTO users JSON ? WITH JSON TRANSFORMS = \{<field>: <fn>\}}}
Problems:
* With SELECT, the number and type of selected columns changes, which is
somewhat quirky.
* It's not possible to select both normal columns and a JSON document that
contains some of the columns.
* Functions cannot be applied to the JSON document. (For example,
{{concat()}}, if we consider aggregation functions.)
h3. Functional Approach
Inserting:
{{INSERT INTO users (id, name, address) VALUES jsonToRow($${'id': ...$$);}}
Selecting:
{{SELECT rowToJson(id, address) FROM users;}}
Possible future enhancements such as default values and transformation
functions can be handled with arguments:
{{INSERT INTO users VALUES jsonToRow(..., \{<field>: <default>\}, \{<field>:
<fn>\})}}
Problems:
* When selecting, field names could get strange with function calls and
subfields (e.g. {{SELECT rowToJson(k, sin(v)) ...}}). We might eventually need
to offer a way to change field names. This could be handled with another
optional argument or perhaps {{AS}} syntax inside the function call.
Although I think the syntax option is somewhat cleaner, the function approach
is more powerful, doesn't require expanding the language, and is probably a bit
more consistent with the rest of CQL. For those reasons, I think we should go
with json functions.
> 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)
