[
https://issues.apache.org/jira/browse/CASSANDRA-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810188#comment-13810188
]
Aleksey Yeschenko commented on CASSANDRA-5590:
----------------------------------------------
1. UserType.isCompatibleWith() has redundant logic - (duplicates
CT.isCompatibleWith() except for the type name comparison bit)
2. DefsTables.mergeTypes() 'extension' check is wrong for for equal-sized yet
compatible user types (will simply pick u1 even if u2 is the most recent one,
timestamp-wise)
3. UserTypes.Literal.toString() is slightly wrong
4. the cf name for user types should probably be schema_usertypes or
schema_user_types - for consistency's sake (and to be able to continue to
reference them as system.schema_* cfs)
5. ALTER TYPE RENAME for the complete type seems to just make a copy of the
original type with a new name. Should drop the original type. Also, should
update all the user types that have the type that's being renamed, updated..
and all the cfs that were using that. IMHO the complexity is not worth it and
we should just drop ALTER TYPE RENAME (the full type rename variant) entirely.
There is always CREATE/DROP/ALTER if a user has to perform a rename, which
should be rare.
6. For auth, we should create a new Resource object and not reuse DataResouce
(GRANT/REVOKE CREATE/ALTER/DROP ON (ALL TYPES|TYPE <name>) TO/FROM <user> - at
least ALL TYPES for now). And/or check for ALTER on all the affected by a
rename/add tables. Will create a separate ticket for that.
Attaching a patch that corrects 1-4, with a dose of OCD on top (feel free to
ignore the OCD part or the whole patch if you've got better versions in mind).
Will also create tickets for cqlsh support (DESCRIBE, SELECT, completion for
create/alter/drop type, updated grant/revoke, etc.)
> 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)
