cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7423) Allow updating individual subfields of UDT
Date Tue, 01 Mar 2016 21:08:18 GMT


Tyler Hobbs commented on CASSANDRA-7423:

Initial patch and CI tests:


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