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:
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:
and to rewrite the users table above as
In terms of inserts we'd need a syntax for those new "struct". Could be:
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:
One open question however is what type do we send back in the result set
for a query like:
- 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.