[
https://issues.apache.org/jira/browse/CASSANDRA-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328097#comment-14328097
]
Tyler Hobbs commented on CASSANDRA-7970:
----------------------------------------
bq. I'd actually have a preference for not allowing the column name declaration
at all as it doesn't buy us anything
There is a minor difference in behavior. If the JSON value map does not
contain an entry for a column listed in the column names, null will be inserted
for that column. Omitting the column names is currently equivalent to listing
them all. An example of the current behavior may clarify this:
{code:sql}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b));
> INSERT INTO foo JSON '{"a": 0, "b": 0, "c": 0, "d": 0}';
> SELECT * FROM foo;
a | b | c | d
---+---+---+---
0 | 0 | 0 | 0
> INSERT INTO foo JSON '{"a": 0, "b": 0, "c": 0}';
> SELECT * FROM foo;
a | b | c | d
---+---+---+------
0 | 0 | 0 | null
{code}
Since column {{d}} didn't have a value in the json map, null was inserted.
However, if we explicitly list the column names (and leave out {{d}}), we can
avoid inserting null:
{code:sql}
> INSERT INTO foo JSON '{"a": 0, "b": 0, "c": 0, "d": 0}';
> INSERT INTO foo (a, b, c) JSON '{"a": 0, "b": 0, "c": 0}';
> SELECT * FROM foo;
a | b | c | d
---+---+---+---
0 | 0 | 0 | 0
{code}
bq. Even if some of our literals can be of multiple types (typically numeric
literals), they will always translate to the same thing in JSON anyway so that
shouldn't be a problem. As for bind markers, we can do what we do for other
functions when their is an ambiguity and require the user to provide a
type-cast. Is it just that it's not convenient to do with the current code, or
is there something more fundamental I'm missing?
Hmm, I think what you suggest should be possible, although it will probably
require a fair amount of code changes, especially for handling literals (which
would probably bypass the whole AbstractType system). Let me play around with
this and get back to you. Would you like to get support for this and the
{{fromJson()}} changes in this patch, or would you be willing to push this to
another ticket?
> 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)
