[
https://issues.apache.org/jira/browse/CASSANDRA-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304029#comment-14304029
]
Tyler Hobbs commented on CASSANDRA-7970:
----------------------------------------
Thanks for the comments, [~snazy]. I've updated the branch with one commit per
comment. A few responses:
bq. Can you add a INSERT JSON variant that tackles tuples and types?
I assume you mean a unit test. If so, that's done.
bq. Was wondering if we really need to mention the column names since they are
contained in the JSON
Good point, I've made the column name declaration optional with doing INSERT
JSON.
bq. The Java Driver tries to contact a coordinator that owns the target
partition \[...\]
We currently have the same problem if any functions are used for the
insert/update. I don't think it's too big of a deal, and I'm not sure that we
have any good solutions right now.
bq. Maybe we can discuss a follow-up that both allows {{VALUES}} and {{JSON}}
I would personally be -1 on that. I don't think it's worth making the query
language more complicated for a networking-related optimization. Plus, if
folks are splitting up JSON to do that anyway, they might as well just use
VALUES all the way.
bq. would be nicer (and eliminate one String instance) to replace
sb.append(JSONValue.escape(columnName)) with something like
JSONValue.escape(columnName, sb)
I would like to do that as well, but JSONValue doesn't support anything like
that. (It's from the JSON.simple library, not our code.) We could always
implement our own escape method, but I'm not sure that's worth it.
bq. ReversedType : not sure whether the impl is correct - doesn’t it need to
reverse the binary representation?
It doesn't. The only thing ReversedType changes is the compare() method. See
fromString(), for example.
bq. FromJsonFct + ToJsonFct : would be nicer to have a CHM instead of
synchronized HashMap.
Done. We should probably also do this for the CollectionType subclasses.
bq. Also these maps in these classes have AbstractType as the key and are never
evicted - means: a changed user type would remain forever in these maps and if
a UDT
Hmm, that's a good point. It's a pretty minor concern, so I would be in favor
of a follow-up ticket (especially considering possible AbstractType changes).
> 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)
