You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksey Yeschenko (JIRA)" <ji...@apache.org> on 2014/08/28 23:41:10 UTC

[jira] [Commented] (CASSANDRA-7423) Allow updating individual subfields of UDT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14114400#comment-14114400 ] 

Aleksey Yeschenko commented on CASSANDRA-7423:
----------------------------------------------

- there is more or less a consensus about UDTs as blobs in its current form being of very limited usefulness 
- making UDTs sub-field resolvable would most likely require the fields to be stored in separate cells
- thus a rather painful migration will be required (like supercolumns, CASSANDRA-3237, bugs from which we are still occasionally finding)
- a lot of other huge changes are planned for 3.0. Tackling them all at once, and UDT migrations on top, might end up being a hellish experience

So I have a controversial suggesting here, especially with 2.1.0 being so close. Maybe (maybe) we should delay UDTs altogether until 3.0, where we'll make them properly sub-field resolvable. The native protocol part won't have to change - we can just remove CREATE/ALTER/DROP TYPE from Cql.g and the docs for 2.1.0, and remove the rest of the code (that needs removal) in 2.1.1+.

> Allow updating individual subfields of UDT
> ------------------------------------------
>
>                 Key: CASSANDRA-7423
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7423
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API, Core
>            Reporter: Tupshin Harper
>              Labels: cql
>
> 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.2#6252)