cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10796) Views do not handle single-column deletions of view PK columns correctly
Date Wed, 02 Dec 2015 19:33:11 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036432#comment-15036432
] 

Carl Yeksigian commented on CASSANDRA-10796:
--------------------------------------------

+1, assuming cassci is happy.

Couple of nits:
- Unused import of {{ByteBufferUtil}} in {{AbstractRow.java}}
- Can we also add a test to ensure that a deletion of a column will be properly tombstoned
when it is included in the view as a regular column, just to prevent a future regression


> Views do not handle single-column deletions of view PK columns correctly
> ------------------------------------------------------------------------
>
>                 Key: CASSANDRA-10796
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10796
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Coordination
>            Reporter: Tyler Hobbs
>            Assignee: Tyler Hobbs
>             Fix For: 3.0.1, 3.1
>
>
> When a materialized view has a regular base column in its primary key, and that regular
base column is deleted through a single-column deletion, the view does not handle it correctly,
and may produce an error.
> For example, with a table like:
> {noformat}
> CREATE TABLE foo (
>     a int, b int, c int, d int
>     PRIMARY KEY (a, b)
> )
> {noformat}
> and a view like:
> {noformat}
> CREATE MATERIALIZED VIEW BAR
>     AS SELECT * FROM foo
>     WHERE ...
>     PRIMARY KEY (a, d, b)
> {noformat}
> a deletion like this will not be handled correctly:
> {noformat}
> DELETE d FROM foo WHERE a = 0 AND b = 0
> {noformat}
> The source of the problem is that we aren't checking whether individual cells in the
TemporalRow are live or not when building the clustering and partition key for the row.  Instead,
we're just using the cell value, which is an empty ByteBuffer.
> I should have a patch with a fix and tests posted tomorrow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message