[
https://issues.apache.org/jira/browse/CASSANDRA-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15175261#comment-15175261
]
Sylvain Lebresne commented on CASSANDRA-7423:
---------------------------------------------
bq. we do not currently require collections inside UDT definitions to be
declared with {{frozen<>}}. They are always implicitly frozen.
It's not really that they are implicitly frozen, it's that we only allow frozne
UDT and frozenness reaches deep. As soon as you froze something, everything
nested is also frozen (rather intuitively I would add), and so I don't think
there is anything wrong with the current behavior. But if this patch only allow
non-frozen UDT at top-level, then I think we should force people to have nested
fields frozen. In other words, we currently allow
{noformat}
CREATE TYPE foo (c set<text>);
CREATE TABLE bar (k int PRIMARY KEY, t frozen<foo>);
{noformat}
and that's fine, but we don't and still shouldn't allow with this patch:
{noformat}
CREATE TABLE bar (k int PRIMARY KEY, t foo);
{noformat}
given the same definition of {{foo}}. What we should allow is:
{noformat}
CREATE TYPE foo (c frozen<set<text>>);
CREATE TABLE bar (k int PRIMARY KEY, t foo);
{noformat}
Assuming we do that, which I strongly think we should, I don't see a backward
compatibility problem supporting nesting non-frozen stuffs.
> Allow updating individual subfields of UDT
> ------------------------------------------
>
> Key: CASSANDRA-7423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7423
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
> Reporter: Tupshin Harper
> Assignee: Tyler Hobbs
> Labels: client-impacting, cql, docs-impacting
> Fix For: 3.x
>
>
> Since user defined types were implemented in CASSANDRA-5590 as blobs (you
> have to rewrite the entire type in order to make any modifications), they
> can't be safely used without LWT for any operation that wants to modify a
> subset of the UDT's fields by any client process that is not authoritative
> for the entire blob.
> When trying to use UDTs to model complex records (particularly with nesting),
> this is not an exceptional circumstance, this is the totally expected normal
> situation.
> The use of UDTs for anything non-trivial is harmful to either performance or
> consistency or both.
> edit: to clarify, i believe that most potential uses of UDTs should be
> considered anti-patterns until/unless we have field-level r/w access to
> individual elements of the UDT, with individual timestamps and standard LWW
> semantics
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
