[
https://issues.apache.org/jira/browse/CASSANDRA-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369330#comment-14369330
]
Sylvain Lebresne commented on CASSANDRA-7970:
---------------------------------------------
bq. It's just to assume the system keyspace if a keyspace isn't set on the
function.
Ok. I still think the whole dealing with keyspace in {{FunctionName}} is
fragile but it's somewhat outside this ticket so I've created CASSANDRA-8994.
bq. However, I'm not clear on what you're suggesting. Can you elaborate?
So, {{AbstractType.fromJSONObject}} would return a {{Term}}. For basic types,
it would be a {{Constants.Value}} but for say a list, it would be a
{{Lists.Value}} (containing the unserialized collection). Then
{{Json.ColumnValue}} would just be a {{Term.Raw}} (not a {{Term.Terminal}}) and
it's {{prepare}} would return the result of {{fromJSONObject}}. The end result
being that {{Lists.Appender.doAppend}} would always get a {{Lists.Value}} and
we won't need {{Lists.getElementsFromValue}}.
bq. We have this problem in other parts of the code as well
Right, and we should fix those some day, but that's another story :)
bq. Plus, the purpose of {{ExecutionException}} is pretty clear right now: it's
for errors that occur while executing a user-defined function.
It's meant for errors while executing functions in general, not necessarily
user-defined ones and I'm absolutely convinced we'll have to use it in native
functions sooner or later. And functions in general can be used in select
clauses, in which case they'll error out during execution, not during
validation, so we shouldn't use IRE for them (as mentioned by Jonathan in [that
comment|https://issues.apache.org/jira/browse/CASSANDRA-5910?focusedCommentId=13746044&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13746044]).
Now, you could say that {{FromJsonFct}} cannot currently be used in select
clauses, but 1) I'm hoping we can fix that at some point and 2) I'd really
prefer consider those JSON functions as normal functions as much as possible,
so I do prefer saying those errors are errors during the execution of a
function rather than "type errors of a sort".
Lastly, a micro nits: you could make {{JSON_IDENTIFIER}} public in
{{Json.java}} and use it in {{Selection}}.
> 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)
