[
https://issues.apache.org/jira/browse/CASSANDRA-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14267409#comment-14267409
]
Sylvain Lebresne commented on CASSANDRA-7970:
---------------------------------------------
I think it might be worth clarifying what we're talking about here because it
appears I don't have the same understanding as some of you guys.
I'm not at all in favor of making CQL weakly typed. We've remove the "accept
string for everything" in CQL early on and I'm still convinced it was a good
thing.
My understanding of Tyler's suggestion is that it's only related to JSON
support. It's to say that if we have the table:
{noformat}
CREATE TABLE foo (
c1 int PRIMARY KEY,
c2 float,
c3 map<int, timestamp>,
)
{noformat}
then we'll agree to map to it a json literal like
{noformat}
{
'c1' : '3',
'c2' : '4.2',
'c3' : { '4', '2011-02-03 04:05'}
}
{noformat}
and this even though the JSON uses strings everywhere. And I think it's ok to
do this because JSON is not really a typed thing in the first place: it has
different kind of literals, but it's not typed per se, and it doesn't support
all the literals that CQL supports anyway (typically uuid literals, which is
why we will have to at least accept string for uuids). But I think it's ok to
do this for the JSON mapping (which again, I just see as considering JSON as
untyped/weakly typed) without going as far as making CQL itself weakly typed.
But if we disagree on that part, and you guys think it would be horribly
inconsistent to accept that kind of thing in the JSON translation without
weakening the CQL typing, then count me as a *strong* -1 on the whole thing.
> 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
>
>
> 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)
