[
https://issues.apache.org/jira/browse/CASSANDRA-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328152#comment-14328152
]
Sylvain Lebresne commented on CASSANDRA-7970:
---------------------------------------------
bq. There is a minor difference in behavior.
I see. But the thing is that we don't really have a way to implement such
difference except at the root level. Meaning that if you have:
{noformat}
INSERT INTO foo JSON '{"a": 0, "b" : { "c" : 1, "d" : 2}}'
{noformat}
where {{b}} is a non-frozen UDT (which we don't have yet but will eventually)
with more than columns {{c}} and {{d}}, we'll have to choose the behavior once
and for all (either it "replace" {{b}} completely, setting it's other column to
null, which is what I think it should do, or it let those other column
untouched). Hence I'm not entirely sure having a special case for the root
level is all that consistent/useful.
Further, while C* doesn't strongly enforce it, we've tried to make it clear
that {{INSERT}} should be used for actual inserts and you should use {{UPDATE}}
for updates. While if you care about the difference between those two variants,
it feels to me that you're using an {{INSERT}} where you should be using an
{{UPDATE}}. So I still would feel more confortable removing the 'with column
name' variant from the initial version, we can always revisit later if it feels
truly useful.
bq. would you be willing to push this to another ticket?
That. My suggestion is indeed a bit involved and is to some extend orthogonal
to this issue (it's more about improving the type system). Let's indeed stick
to simple rejection when we don't know how to handle it for now. We can
scratch my itch later :)
> 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
> Labels: client-impacting, cql3.3, docs-impacting
> 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)
