[ https://issues.apache.org/jira/browse/CASSANDRA-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810213#comment-13810213 ]
Aleksey Yeschenko commented on CASSANDRA-5590: ---------------------------------------------- (I'm fine with the current checkAccess() implementations, so that's not a blocker). > 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)