cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7423) Allow updating individual subfields of UDT
Date Wed, 02 Mar 2016 08:30:18 GMT


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
CREATE TYPE foo (c set<text>);
CREATE TABLE bar (k int PRIMARY KEY, t frozen<foo>);
and that's fine, but we don't and still shouldn't allow with this patch:
CREATE TABLE bar (k int PRIMARY KEY, t foo);
given the same definition of {{foo}}. What we should allow is:
CREATE TYPE foo (c frozen<set<text>>);
CREATE TABLE bar (k int PRIMARY KEY, t foo);
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:
>             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

View raw message