[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16671:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: Code Inspection
Fix Version/s: 4.0.x
3.11.x
3.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used and {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion. The expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null));
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16671:
---
Description:
It is the semantic of CQL that a (CQL) row exists as long as it has one
non-null column (including the PK columns).
To determine if a row has some *non-null primary key*, Cassandra relies on the
row primary key liveness.
For example:
{code}
CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
DELETE v FROM test WHERE pk = 1 AND ck = 1
SELECT v FROM test;
{code}
will return
{code}
v
---
null
{code}
{{UPDATE}} statements do not set the row primary key liveness by consequence if
the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
{{SELECT}} query would *not have returned any rows*.
CASSANDRA-16226 introduced a regression by stopping early in the timestamp
ordered logic if an {{UPDATE}} statement covering all the columns was found in
an SSTable. As the row returned did not have a primary key liveness if another
node was also returning a column deletion, the expected row will not be
returned.
The problem can be reproduced with the following test:
{code}
@Test
public void
testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
Throwable
{
try (Cluster cluster = init(builder().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int, ck
text, v int, PRIMARY KEY (pk, ck))"));
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
(pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
cluster.get(1).flush(KEYSPACE);
cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
cluster.get(1).flush(KEYSPACE);
cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
cluster.get(2).flush(KEYSPACE);
assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
row(1, "1", null));
assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
row((Integer) null));
}
}
{code}
cc: [~maedhroz], [~ifesdjeen]
was:
It is the semantic of CQL that a (CQL) row exists as long as it has one
non-null column (including the PK columns).
To determine if a row has some *non-null primary key*, Cassandra relies on the
row primary key liveness.
For example:
{code}
CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
DELETE v FROM test WHERE pk = 1 AND ck = 1
SELECT v FROM test;
{code}
will return
{code}
v
---
null
{code}
{{UPDATE}} statements do not set the row primary key liveness by consequence if
the user had used and {{UPDATE}} statement instead of an {{INSERT}} the
{{SELECT}} query would *not have returned any rows*.
CASSANDRA-16226 introduced a regression by stopping early in the timestamp
ordered logic if an {{UPDATE}} statement covering all the columns was found in
an SSTable. As the row returned did not have a primary key liveness if another
node was also returning a column deletion. The expected row will not be
returned.
The problem can be reproduced with the following test:
{code}
@Test
public void
testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
Throwable
{
try (Cluster cluster = init(builder().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int, ck
text, v int, PRIMARY KEY (pk, ck))"));
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
(pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
cluster.get(1).flush(KEYSPACE);
cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
cluster.get(1).flush(KEYSPACE);
cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
cluster.get(2).flush(KEYSPACE);
assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
row(1, "1", null));
assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
row((Integer) null));
}
}
{code}
cc: [~maedhroz], [~ifesdjeen]
> Cassandra can return no row when the row columns have been deleted.
> --
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16671:
---
Description:
It is the semantic of CQL that a (CQL) row exists as long as it has one
non-null column (including the PK columns).
To determine if a row has some *non-null primary key*, Cassandra relies on the
row primary key liveness.
For example:
{code}
CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
DELETE v FROM test WHERE pk = 1 AND ck = 1
SELECT v FROM test;
{code}
will return
{code}
v
---
null
{code}
{{UPDATE}} statements do not set the row primary key liveness by consequence if
the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
{{SELECT}} query would *not have returned any rows*.
CASSANDRA-16226 introduced a regression by stopping early in the timestamp
ordered logic if an {{UPDATE}} statement covering all the columns was found in
an SSTable. As the row returned did not have a primary key liveness if another
node was also returning a column deletion, the expected row will not be
returned.
The problem can be reproduced with the following test:
{code}
@Test
public void
testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
Throwable
{
try (Cluster cluster = init(builder().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int, ck
text, v int, PRIMARY KEY (pk, ck))"));
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
(pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
cluster.get(1).flush(KEYSPACE);
cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
cluster.get(1).flush(KEYSPACE);
cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
cluster.get(2).flush(KEYSPACE);
assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
row(1, "1", null)); // <-- FAIL
assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
row((Integer) null));
}
}
{code}
cc: [~maedhroz], [~ifesdjeen]
was:
It is the semantic of CQL that a (CQL) row exists as long as it has one
non-null column (including the PK columns).
To determine if a row has some *non-null primary key*, Cassandra relies on the
row primary key liveness.
For example:
{code}
CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
DELETE v FROM test WHERE pk = 1 AND ck = 1
SELECT v FROM test;
{code}
will return
{code}
v
---
null
{code}
{{UPDATE}} statements do not set the row primary key liveness by consequence if
the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
{{SELECT}} query would *not have returned any rows*.
CASSANDRA-16226 introduced a regression by stopping early in the timestamp
ordered logic if an {{UPDATE}} statement covering all the columns was found in
an SSTable. As the row returned did not have a primary key liveness if another
node was also returning a column deletion, the expected row will not be
returned.
The problem can be reproduced with the following test:
{code}
@Test
public void
testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
Throwable
{
try (Cluster cluster = init(builder().withNodes(2).start()))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int, ck
text, v int, PRIMARY KEY (pk, ck))"));
cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
(pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
cluster.get(1).flush(KEYSPACE);
cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
cluster.get(1).flush(KEYSPACE);
cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
cluster.get(2).flush(KEYSPACE);
assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
row(1, "1", null));
assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
row((Integer) null));
}
}
{code}
cc: [~maedhroz], [~ifesdjeen]
> Cassandra can return no row when the row columns have been deleted.
> ---
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16671:
Reviewers: Caleb Rackliffe
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion, the expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null)); // <-- FAIL
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16671:
---
Fix Version/s: (was: 4.0.x)
4.0-rc
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion, the expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null)); // <-- FAIL
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16671:
---
Test and Documentation Plan: The patches add several extra unit tests and
in-jvm dtests
Status: Patch Available (was: In Progress)
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion, the expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null)); // <-- FAIL
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16671:
Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Status: Review In Progress (was: Patch Available)
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion, the expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null)); // <-- FAIL
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16671:
Fix Version/s: 4.x
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc, 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion, the expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null)); // <-- FAIL
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16671:
---
Fix Version/s: (was: 4.0-rc)
(was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
4.0
4.0-rc2
3.11.11
3.0.25
Since Version: 3.11.10
Source Control Link:
https://github.com/apache/cassandra/commit/24346d17899df8610a5f425c7074ddd5dc8082bb
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into 3.0 at 24346d17899df8610a5f425c7074ddd5dc8082bb and merged into
3.11, 4.0.0, 4.0 and trunk
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion, the expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null)); // <-- FAIL
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
