[
https://issues.apache.org/jira/browse/CASSANDRA-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774487#comment-13774487
]
Sylvain Lebresne commented on CASSANDRA-5590:
---------------------------------------------
Attaching patch for this at https://github.com/pcmanus/cassandra/commits/5590
(5 last patches).
The syntax is the one of the description above (including the syntax to select
specific fields). The user types are global (they are not keyspace scoped for
instance; figured scoping them would be annoying in practice without any
benefits that I can see).
Internally, the cell value for a user type uses the same format than
CompositeType (a feature) and the new 'UserType' AbstractType is in fact just a
subtype of CompositeType with additional metadata. This makes it possible for
users using a CompositeType as a CQL3 column value today to update to a user
type later.
The patches implement 3 new CQL3 statements: CREATE TYPE, ALTER TYPE and DROP
TYPE. DROP only lets you drop types that are not in use in any existing table.
ALTER allows to:
# rename fields
# alter the type of an existing fields (provided the new type is compatible
with the old one).
# rename the type itself
# append new fields to an existing types: we can't allow dropping fields
however, so it's a one-way street.
I'll note that currently we send the full user type definition in resultSet
metadata like we do for custom types. Meaning a pretty long string with fully
qualified java class names in it. It's not a hug deal in itself since the v2
protocol allows to skip said metadata for prepared statement (and for
non-prepared statement in fact provided the client have some means to figure
out the metadata on its own). That being said, we should add some special code
for user types in the native protocol to make this a lot more compact, but that
means starting the v3 version of the protocol and that can probably be left to
a followup ticket.
The patches also don't update cqlsh to make it understand user type values so
they currently show as blobs. Also can be done in a followup ticket imo.
Note: the last patch makes the name of aleksey first list above not available
for user type (in provision of some potential future use). I haven't added the
geometric ones though, because I'm not too keen on the idea of doing geometric
stuffs in core Cassandra ever (but if someone feels strongly we should reserve
those nonetheless I'm not going to fight on this).
> 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
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
