[
https://issues.apache.org/jira/browse/CASSANDRA-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157292#comment-14157292
]
Tyler Hobbs commented on CASSANDRA-7970:
----------------------------------------
bq. I guess I don't see how this is more quirky than number and type of
selected columns changing in a non-json select.
We don't normally do that in a non-json select, though. (The one exception I
can think of is selecting duplicate columns, like {{SELECT a, b, a FROM}}.)
With {{SELECT JSON a, b, c}}, you get back one column. I'm not saying this is
terrible behavior, but it's definitely an exception to the way things normally
work.
bq. What I mean by this is, all other function calls should have the same
behavior whether called on a literal or a column with the same value. Thus,
sin(2) and sin(a) where a=2 are semantically equivalent. But row_to_json(a) has
to cheat and generate...
Currently we don't allow selecting constants or function calls, so technically
that's not an issue yet, but I guess it's only a matter of time until we do
support that. {{rowToJson()}} would use the natural identifiers of selections
as field names for where possible (columns, subfields, etc) and use the
constant or function call as the field name otherwise. So for example,
{{SELECT rowToJson(2, now(), a) FROM ...}} would return \{'2': 2, 'now()':
1234567, 'a': 'foo'\}. This could be overridden with additional arguments or
{{AS}} syntax.
bq. (Unless you are saying that row_to_json(a) would generate just the literal
2, in which case I have to say that having to spell out all the json fields is
insufficiently usable to be a viable candidate.)
Nope, agreed.
bq. Postgresql gets around this with subselects and the concept of a row
constructor
I agree that subselects are not something we want to introduce. Row
constructors might internally simplify some of the typing issues, but from an
API perspective they're roughly equivalent to my proposal (unless I'm missing
some advantage).
> 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)
