cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Kania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8480) Update of primary key should be possible
Date Tue, 16 Dec 2014 16:13:13 GMT


Jason Kania commented on CASSANDRA-8480:

Thanks for the response and explanation.

I am quite certain that with all your combined efforts to date you are looking to make Cassandra
as usable as possible. It is just a question of what you rule out as possible versus documenting
as performance impacting. I have worked in the capacity of performance architect on several
large scale production systems and have had to balance user needs versus performance many
times. My experience is that when choosing between stopping what users can do versus having
the big flashing danger sign, the big flashing danger sign is usually what the end users are
looking for.

I would suggest that it might be worth polling users about which approach would work versus
falling back to core principles that may not be in the best interests of wider product adoption.

> Update of primary key should be possible
> ----------------------------------------
>                 Key: CASSANDRA-8480
>                 URL:
>             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

View raw message