[
https://issues.apache.org/jira/browse/CASSANDRA-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14248485#comment-14248485
]
Aleksey Yeschenko commented on CASSANDRA-8480:
----------------------------------------------
You are not wrong. But it's not just about core principles (which are
important, but not the only things that matters). It's also about complexity.
Imagine a query like `UPDATE foo SET partition_key = 'bar' WHERE partition_key
= 'baz'`. Executing it would involve reading the whole partition (potentially
from many nodes, depending on CL), and very likely streaming it to a whole new
set of replicas. This would require an entirely new write code path, and would
break in spectacular ways from time to time. Operations like that are what
Spark is for, not a good fit for CQL. Besides, it would not be idempotent, and
writes must be idempotent in C* (with the exception of counters, and let's
forget about lists for a second).
Ultimately, this is not an often-requested feature, if at all, and it's not
something that can be implemented *well* on the Cassandra side, if at all, in a
general way. So, on balance (complexity of implementation plus fundamental
incompatibility with Cassandra write path vs. users' desire for the feature)
the chances of this wish materializing are not high. Sorry.
> Update of primary key should be possible
> ----------------------------------------
>
> Key: CASSANDRA-8480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8480
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Reporter: Jason Kania
>
> While attempting to update a column in a row, I encountered the error
> PRIMARY KEY part thingy found in SET part
> The error is not helpful as it doesn't state why this is problem so I looked
> on google and encountered many, many entries from people who have experienced
> the issue including those with single column table who have to hack to work
> around this.
> After looking around further in the documentation, I discovered that it is
> not possible to update a primary key but I still have not found a good
> explanation. I suspect that that this is because it would change the indexing
> location of the record effectively requiring a delete followed by an insert.
> If the question is one of guaranteeing no update to a deleted row, a client
> will have the same issue.
> To me, this really should be handled behind the API because:
> 1) it is an expected capability in a database to update all columns and
> having these limitations only puts off potential users especially when they
> have to discover the limitation after the fact
> 2) being able to use a column in a WHERE clause requires it to be part of the
> primary key so what this limitation means is if you can update a column, you
> can't search for it, or if you can search on a column, you can't update it
> which leaves a serious gap in handling a wide number of use cases.
> 3) deleting and inserting a row with an updated primary key will mean sucking
> in all the data from the row up to the client and sending it all back down
> even when a single column in the primary key was all that was updated.
> Why not document the issue but make the interface more usable by supporting
> the operation?
> Jason
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
