cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5590) User defined types for CQL3
Date Thu, 07 Nov 2013 22:05:18 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13816483#comment-13816483
] 

Aleksey Yeschenko commented on CASSANDRA-5590:
----------------------------------------------

bq. Shouldn't the fix be in the driver, not in cqlsh?

cassandra-dbapi2 will likely not have another release. and python-driver, even if we switch
to it tomorrow, doesn't support user types natively. So yes, it has to be done in cqlsh.

> User defined types for CQL3
> ---------------------------
>
>                 Key: CASSANDRA-5590
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5590
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 2.1
>
>         Attachments: ocd-and-corrections-patch.txt
>
>
> A typical use case for a collection could be to store a bunch of addresses in a user
profile. An address could typically be composed of a few properties: say a street, a city,
a postal code and maybe a few phone numbers associated to it.
> To model that currently with collections, you might use a {{map<string, blob>}},
where the map key could be a string identifying the address, and the value would be all the
infos of an address serialized manually (you can use {{text}} instead of {{blob}} and shove
everything in a string if you prefer but the principle is the same).
> This ticket suggests to make this more user friendly by allowing:
> {noformat}
> CREATE TYPE address (
>   street text,
>   city text,
>   zip_code int,
>   phones set<text>
> )
> CREATE TABLE users (
>   id uuid PRIMARY KEY,
>   name text,
>   addresses map<string, address>
> )
> {noformat}
> Under the hood, that type declaration would just be metadata on top of CompositeType
(which does mean a limitation would be that we wouldn't allow re-ordering or removal of fields
in a custom TYPE). Namely, the {{address}} type would be in practice a {{CompositeType(UTF8Type,
UTF8Type, Int32Type, SetType(UTF8Type))}} + some metadata that records the name of each component.
 In other words, this would mostly be user-friendly syntactic sugar to create composite blobs.
> I'll note that this would also be useful outside collections, as it might sometimes be
more efficient/useful to have such simple composite blob. For instance, you could imagine
to have a:
> {noformat}
> CREATE TYPE fullname (
>   firstname text,
>   lastname text
> )
> {noformat}
> and to rewrite the {{users}} table above as
> {noformat}
> CREATE TABLE users (
>   id uuid PRIMARY KEY,
>   name fullname,
>   addresses map<string, address>
> )
> {noformat}
> In terms of inserts we'd need a syntax for those new "struct". Could be:
> {noformat}
> INSERT INTO users (id, name)
>            VALUES (2ad..., { firstname: 'Paul', lastname: 'smith'});
> UPDATE users
>    SET addresses = address + { 'home': { street: '...', city: 'SF', zip_code: 94102,
phones: {} } }
>    WHERE id=2ad...;
> {noformat}
> where the difference with a map is that the "key" would be a column name (in the CQL3
sense), not a value/literal. Though we might find that a bit confusing and find some other
syntax.
> On the query side, we could optionally allow things like:
> {noformat}
> SELECT name.firstname, name.lastname FROM users WHERE id=2ad...;
> {noformat}
> One open question however is what type do we send back in the result set
> for a query like:
> {noformat}
> SELECT name FROM users WHERE id=2ad...;
> {noformat}
> We could:
> # return just that it's the user defined type named {{address}}, but that imply the client
has to query the cluster metadata to find out the definition of the type.
> # return the full definition of the type every time.
> I also note that client side, it might be a tad harder to support such types cleanly
in statically type languages than in dynamically typed ones, but that's not the end of the
world either. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message