[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=16387459#comment-16387459 ] Benjamin Lerer commented on CASSANDRA-7423: --- Can you create a separate ticket? > 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 >Priority: Major > Labels: client-impacting, cql, docs-impacting > Fix For: 3.6 > > > 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 (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[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=16386662#comment-16386662 ] Bhanu M. Gandikota commented on CASSANDRA-7423: --- Hi I got the following error stack during "nodetool upgrades stables" [from 2.2.5 to 3.11.1]. What do I need to do ? -bash-4.2$ nodetool upgradesstables WARN 11:28:28,430 Small cdc volume detected at /cdc_raw; setting cdc_total_space_in_mb to 1982. You can override this in cassandra.yaml error: null -- StackTrace -- java.lang.AssertionError at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:43) at org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1242) at org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1185) at org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:495) at org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:472) at org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:306) at org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.readStaticRow(SSTableSimpleIterator.java:176) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.(SSTableIdentityIterator.java:49) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.create(SSTableIdentityIterator.java:59) at org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:384) at org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48) at org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:70) at org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:122) at org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:113) at org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:466) at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) at org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:163) at org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:92) at org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:233) at org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:196) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85) at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61) at org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:428) at org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:315) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81) at java.lang.Thread.run(Thread.java:745) > 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 >Priority: Major > Labels: client-impacting, cql, docs-impacting > Fix For: 3.6 > > > 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
[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=15232141#comment-15232141 ] Benjamin Lerer commented on CASSANDRA-7423: --- Your change seems to have fixed the problem :-) Thanks. +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: CQL >Reporter: Tupshin Harper >Assignee: Tyler Hobbs > Labels: client-impacting, cql, docs-impacting > Fix For: 3.6 > > > 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)
[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=15229301#comment-15229301 ] Tyler Hobbs commented on CASSANDRA-7423: bq. can you add an entry to the CQL doc changelog and include a link to the ticket in that entry I did have an entry, but I've added the ticket number there as well. bq. whereas I would have expected on the following line (or even better: a b ) Hmm, I can't reproduce getting on the same line. Can we investigate that in another ticket? However, I have taken your suggestion of autocompleting the UDT fields where possible (update assignments and conditions). > 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)
[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=15228433#comment-15228433
]
Benjamin Lerer commented on CASSANDRA-7423:
---
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
u v
cqlsh:test> update test2 set u
= .
{code}
but if I press TAB after {{update test SET u.}} I get:
{code}
cqlsh:test> update test SET u.
{code}
whereas I would have expected {{}} 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)
[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=15227911#comment-15227911 ] Sylvain Lebresne commented on CASSANDRA-7423: - Very minor nit (haven't looked at the patch) but can you add an entry to the CQL doc changelog and include a link to the ticket in that entry (I know we used to not do the latter but lets try to take the habit to as it was suggested to me it would be useful to some people and that's easy to do). > 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)
[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=15227205#comment-15227205 ] Tyler Hobbs commented on CASSANDRA-7423: Thanks for the thorough review! I've fixed all of your nits in a single commit. I also pushed two separate commits to update the CQL docs and cqlsh autocompletion. > 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)
[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=15226037#comment-15226037
]
Benjamin Lerer commented on CASSANDRA-7423:
---
The patch seems pretty good. :-)
The 2 missing things are the CQL documentation and the CQLSH auto completion
for field update/deletion.
Otherwise, I have found the following nits:
* In {{AbstractMarker}} and {{FunctionCall}} the {{else}} are not needed as all
the if end with return statements.
* It seems to me that the signature of {{Operation.RawUpdate::prepare}} method
could be improved by removing the keyspace name (it can be retrieved from
cfm.ksName) and making cfm the first parameter.
* In {{AbstractFunction}} and {{Selector}} I think that
{{receiver.type.isFrozenCollection() || (receiver.type.isUDT() &&
!receiver.type.isMultiCell())}} should be changed.
In my opinion, we could add a {{isFreezable}} method to {{AbstractType}}
({{receiver.type.isFreezable() && !receiver.type.isMultiCell()}}) or use a
{{isFrozenUDT}} method.
* In the {{TulpeType}} constructor it seems that the code:
{code}
for (int i = 0; i < types.size(); i++)
{
AbstractType type = types.get(i);
if (freezeInner)
type = type.freeze();
types.set(i, type);
}
{code}
could be written:
{code}
if (freezeInner)
types.forEach(AbstractType::freeze);
{code}
* In {{CollectionType::serializeForNativeProtocol}} the def parameter is not
used and can be removed (it was there before the patch).
* It might make sense to pass the protocol version to the
{{UDType::serializeForNativeProtocol}} like for
{{CollectionType::serializeForNativeProtocol}} even if it is not used for the
moment.
* I like a lot the {{beforeAndAfterFlush}} method used in {{UserTypesTest}}.
Could you put in {{CQLTester}} instead? There is several places where I would
like to use it. :-)
> 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)
[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=15176045#comment-15176045 ] Tyler Hobbs commented on CASSANDRA-7423: That makes sense -- I'm not sure why I didn't think of that yesterday. I've force-pushed an update to the branch that checks for non-frozen collections nested within non-frozen UDTs when creating a table. > 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)
[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=15175261#comment-15175261
]
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
{noformat}
CREATE TYPE foo (c set);
CREATE TABLE bar (k int PRIMARY KEY, t frozen);
{noformat}
and that's fine, but we don't and still shouldn't allow with this patch:
{noformat}
CREATE TABLE bar (k int PRIMARY KEY, t foo);
{noformat}
given the same definition of {{foo}}. What we should allow is:
{noformat}
CREATE TYPE foo (c frozen);
CREATE TABLE bar (k int PRIMARY KEY, t foo);
{noformat}
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: 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)
[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=15174404#comment-15174404
]
Tyler Hobbs commented on CASSANDRA-7423:
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)
[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-tabpanelfocusedCommentId=14123474#comment-14123474
]
Robert Stupp commented on CASSANDRA-7423:
-
One question (just for understanding):
Would this mean that each deeply nested field is persisted individually?
For a user-type in a user-type it would lead to a column-name
{{upperTypeCol:fieldA:deepTypeFieldA}} (with imaginary column upperTypeCol of
type upperType.
But a {{set}} or {{list}} or {{map}} with user types or collections - wouldn't
these require blob serialization?
AFAIK are {{set}}s serialized with column names like
columnName:setElementValue.
I think blob serialization must occur at a certain nesting/usage level - for
example when a UDT is used as a map value - or when a UDT is used in a {{list}}
(for convenience, when list elements are inserted/removed).
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.3.4#6332)
[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-tabpanelfocusedCommentId=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)
