[
https://issues.apache.org/jira/browse/CASSANDRA-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14246642#comment-14246642
]
Aleksey Yeschenko commented on CASSANDRA-8480:
----------------------------------------------
The explanation for this is that primary key columns are internally parts of
the cell name (or a partition's key), not a cell's value. And while you can
update a cell's value, you can't update its name (and most certainly not a
partition key).
Indeed, we kinda sorta maybe could implement it by deleting the old record
entirely and writing a totally new one behind the scenes. I don't see a way to
make it eventually consistent, however. Plus, it's at best debatable whether or
not further hiding what's really going internally is a good thing.
If you need to update part of primary key, then in Cassandra view, you've
modeled your schema incorrectly, and should redesign it.
> 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)
