[
https://issues.apache.org/jira/browse/CASSANDRA-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228433#comment-15228433
]
Benjamin Lerer edited comment on CASSANDRA-7423 at 4/8/16 12:50 PM:
--------------------------------------------------------------------
I see a weird behavior when playing with auto-completion.
{code}
cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> use test;
cqlsh:test> create type t (a int, b int);
cqlsh:test> create table test (pk int primary key, u t, v int);
cqlsh:test> update test set <TAB>
u v
cqlsh:test> update test set u <TAB>
= .
{code}
but if I press TAB after {{update test SET u.}} I get:
{code}
cqlsh:test> update test SET u.<identifier>
{code}
whereas I would have expected {{<identifier>}} on the following line (or even
better: {{a b}} ;-))
was (Author: blerer):
I see a weird behavior when playing with auto-completion.
{code}
cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> use test;
cqlsh:test> create type t (a int, b int);
cqlsh:test> create table test (pk int primary key, u t, v int);
cqlsh:test> update test set <TAB>
u v
cqlsh:test> update test2 set u <TAB>
= .
{code}
but if I press TAB after {{update test SET u.}} I get:
{code}
cqlsh:test> update test SET u.<identifier>
{code}
whereas I would have expected {{<identifier>}} on the following line (or even
better: {{a b}} ;-))
> 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)
