cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7970) JSON support for CQL
Date Thu, 19 Mar 2015 13:52:41 GMT


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|]).
 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 {{}} and use it
in {{Selection}}.

> JSON support for CQL
> --------------------
>                 Key: CASSANDRA-7970
>                 URL:
>             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>
> );
> {‘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]
> [2]
> [3]

This message was sent by Atlassian JIRA

View raw message