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

["Tyler Hobbs (JIRA)" <ji...@apache.org>]

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

Tyler Hobbs edited comment on CASSANDRA-7423 at 3/1/16 9:08 PM:
----------------------------------------------------------------

Initial patch and CI tests:

||branch||testall||dtest||
|[CASSANDRA-7423|https://github.com/thobbs/cassandra/tree/CASSANDRA-7423]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-dtest]|

I've also opened a [dtest pull request|https://github.com/riptano/cassandra-dtest/pull/829].

This adds support for non-frozen UDTs, which support single-field updates and deletions.  I've also added LWT support for UDTs (both on the value of individual fields and the entire UDT) to match what we support with collections.  This patch does _not_ add support for nesting non-frozen UDTs and collections -- nested types must still be frozen.

I would like to defer the optimization of selecting a single field from a non-frozen UDT to another ticket.  (Currently, we fetch all fields from disk, then extract the selected fields.)  We have roughly two months until the 3.6 release, and I have some higher priority work that I'd like to handle first.

There's also one tricky related issue: we do not currently require collections inside UDT definitions to be declared with {{frozen<>}}.  They are always implicitly frozen.  If we ever want to support nesting non-frozen collections inside non-frozen UDTs (without introducing new syntax or breaking backwards compat), we need to deprecate and warn on the current behavior, and then require {{frozen<>}}.  That can also be done in a separate ticket, but I wanted to raise the issue here.


was (Author: thobbs):
Initial patch and CI tests:

||branch||testall||dtest||
|[CASSANDRA-7423|https://github.com/thobbs/cassandra/tree/CASSANDRA-7423]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-dtest]|

This adds support for non-frozen UDTs, which support single-field updates and deletions.  I've also added LWT support for UDTs (both on the value of individual fields and the entire UDT) to match what we support with collections.  This patch does _not_ add support for nesting non-frozen UDTs and collections -- nested types must still be frozen.

I would like to defer the optimization of selecting a single field from a non-frozen UDT to another ticket.  (Currently, we fetch all fields from disk, then extract the selected fields.)  We have roughly two months until the 3.6 release, and I have some higher priority work that I'd like to handle first.

There's also one tricky related issue: we do not currently require collections inside UDT definitions to be declared with {{frozen<>}}.  They are always implicitly frozen.  If we ever want to support nesting non-frozen collections inside non-frozen UDTs (without introducing new syntax or breaking backwards compat), we need to deprecate and warn on the current behavior, and then require {{frozen<>}}.  That can also be done in a separate ticket, but I wanted to raise the issue here.

> 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)