[
https://issues.apache.org/jira/browse/CASSANDRA-20828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18041935#comment-18041935
]
David Capwell commented on CASSANDRA-20828:
-------------------------------------------
not tested but I think the following transaction has the same issue
{code}
BEGIN TRANSACTION
UPDATE tbl SET c[0] = 42 WHERE pk=42;
COMMIT TRANSACTION
{code}
When accord updates timestamps it doesn't know "how" a Cell was generated, so
will update "c[0]"'s timestamp.
This problem doesn't look to be isolated to the regular CQL path going to
accord and seems to be a limitation with Accord's implementation of cell
timestamp rewriting all together.
> When a table is writing to accord and the mutation is a regular CQL mutation,
> if a multi cell list was written the cell path's timestamp did not reflect
> the transaction timestamp
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-20828
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20828
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Accord
> Reporter: David Capwell
> Assignee: David Capwell
> Priority: Normal
> Fix For: 6.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a list type is written in CAS or BEGIN TRANSACTION we have a custom
> Updater that defines what the cell path should be for the list type, but when
> you used regular CQL we fall back to wall clock time. We normally allow this
> in accord as we rewrite the timestamps during the write phase but the list
> cell path was not updated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
