[jira] [Commented] (CASSANDRA-14404) Transient Replication & Cheap Quorums: Decouple storage requirements from consensus group size using incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448626#comment-16448626 ] Duarte Nunes commented on CASSANDRA-14404: -- Ah, CL is now a function of RF + count(Witnesses). > Transient Replication & Cheap Quorums: Decouple storage requirements from > consensus group size using incremental repair > --- > > Key: CASSANDRA-14404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14404 > Project: Cassandra > Issue Type: New Feature > Components: Coordination, Core, CQL, Distributed Metadata, Hints, > Local Write-Read Paths, Materialized Views, Repair, Secondary Indexes, > Testing, Tools >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Transient Replication is an implementation of [Witness > Replicas|http://www2.cs.uh.edu/~paris/MYPAPERS/Icdcs86.pdf] that leverages > incremental repair to make full replicas consistent with transient replicas > that don't store the entire data set. Witness replicas are used in real world > systems such as Megastore and Spanner to increase availability inexpensively > without having to commit to more full copies of the database. Transient > replicas implement functionality similar to upgradable and temporary replicas > from the paper. > With transient replication the replication factor is increased beyond the > desired level of data redundancy by adding replicas that only store data when > sufficient full replicas are unavailable to store the data. These replicas > are called transient replicas. When incremental repair runs transient > replicas stream any data they have received to full replicas and once the > data is fully replicated it is dropped at the transient replicas. > Cheap quorums are a further set of optimizations on the write path to avoid > writing to transient replicas unless sufficient full replicas are available > as well as optimizations on the read path to prefer reading from transient > replicas. When writing at quorum to a table configured to use transient > replication the quorum will always prefer available full replicas over > transient replicas so that transient replicas don't have to process writes. > Rapid write protection (similar to rapid read protection) reduces tail > latency when full replicas are temporarily late to respond by sending writes > to additional replicas if necessary. > Transient replicas can generally service reads faster because they don't have > do anything beyond bloom filter checks if they have no data. With vnodes and > larger size clusters they will not have a large quantity of data even in > failure cases where transient replicas start to serve a steady amount of > write traffic for some of their transiently replicated ranges. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14404) Transient Replication & Cheap Quorums: Decouple storage requirements from consensus group size using incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447871#comment-16447871 ] Duarte Nunes commented on CASSANDRA-14404: -- Still haven't read the linked paper, but this is pretty much sloppy quorums, no? Also, out of curiosity, how will this intersect with materialized views? Will a transient replica have a paired transient view replica, will it use the paired view replica of the base replica on which behalf it is accepting a write, or will it simply not call into the view write path? > Transient Replication & Cheap Quorums: Decouple storage requirements from > consensus group size using incremental repair > --- > > Key: CASSANDRA-14404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14404 > Project: Cassandra > Issue Type: New Feature > Components: Coordination, Core, CQL, Distributed Metadata, Hints, > Local Write-Read Paths, Materialized Views, Repair, Secondary Indexes, > Testing, Tools >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Transient Replication is an implementation of [Witness > Replicas|http://www2.cs.uh.edu/~paris/MYPAPERS/Icdcs86.pdf > (https://www.google.com/url?sa=t=j==s=web=1=rja=8=0ahUKEwi834a%E2%80%948HaAhWCneAKHdj8DzAQFggpMAA=http%3A%2F%2Fwww2.cs.uh.edu%2F~paris%2FMYPAPERS%2FIcdcs86.pdf=AOvVaw0GfCaaAtdzHiM65du1-qeI)] > that leverages incremental repair to make full replicas consistent with > transient replicas that don't store the entire data set. Witness replicas are > used in real world systems such as Megastore and Spanner to increase > availability inexpensively without having to commit to more full copies of > the database. Transient replicas implement functionality similar to > upgradable and temporary replicas from the paper. > With transient replication the replication factor is increased beyond the > desired level of data redundancy by adding replicas that only store data when > sufficient full replicas are unavailable to store the data. These replicas > are called transient replicas. When incremental repair runs transient > replicas stream any data they have received to full replicas and once the > data is fully replicated it is dropped at the transient replicas. > Cheap quorums are a further set of optimizations on the write path to avoid > writing to transient replicas unless sufficient full replicas are available > as well as optimizations on the read path to prefer reading from transient > replicas. When writing at quorum to a table configured to use transient > replication the quorum will always prefer available full replicas over > transient replicas so that transient replicas don't have to process writes. > Rapid write protection (similar to rapid read protection) reduces tail > latency when full replicas are temporarily late to respond by sending writes > to additional replicas if necessary. > Transient replicas can generally service reads faster because they don't have > do anything beyond bloom filter checks if they have no data. With vnodes and > larger size clusters they will not have a large quantity of data even in > failure cases where transient replicas start to serve a steady amount of > write traffic for some of their transiently replicated ranges. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14393) Incorrect view updates
Duarte Nunes created CASSANDRA-14393:
Summary: Incorrect view updates
Key: CASSANDRA-14393
URL: https://issues.apache.org/jira/browse/CASSANDRA-14393
Project: Cassandra
Issue Type: Bug
Components: Materialized Views
Reporter: Duarte Nunes
Consider the following:
{noformat}
create table t (p int, c int, v1 int, v2 int, primary key(p, c));
create materialized view mv as select p, c, v1 from t
where p is not null and c is not null primary key (c, p);
insert into t (p, c, v1, v2) VALUES(1, 1, 1, 1) using ttl 5;
update t using ttl 1000 set v2 = 1 where p = 1 and c = 1;
delete v2 from t where p = 1 and c = 1;
// Wait 5 seconds
select * from mv;
c | p | v1
---+---+--
1 | 1 | null{noformat}
The view row should be dead after 5 seconds, but it is not.
This is because the liveness info calculated when deleting v2 is based on the
base table update liveness info, which has the timestamp of the first insert
statement. That liveness info is shadowed by the liveness info created in the
update, which has a higher timestamp.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14345) Empty partition keys allowed in MV, but not in normal table
[
https://issues.apache.org/jira/browse/CASSANDRA-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415605#comment-16415605
]
Duarte Nunes commented on CASSANDRA-14345:
--
This seems to be related how composites are serialized (as-is), versus how
multi-component are serialized ( ).
It's not clear to me whether the issue is at the MV level, or whether empty,
non-null keys should be allowed for normal tables too.
> Empty partition keys allowed in MV, but not in normal table
> ---
>
> Key: CASSANDRA-14345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14345
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
>Reporter: Duarte Nunes
>Priority: Major
> Labels: materializedviews
>
> Given the following table:
>
> {code:java}
> cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> create table t (p text, c int, v text, primary key (p));
> cqlsh> use ks;
> {code}
> The following fails:
> {code:java}
> cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
> However, MVs don't appear to have this restriction:
> {code:java}
> create materialized view mv as select * from t where v is not null and p is
> not null and c is not null primary key (v, p);
> insert into t (p, c, v) values ('a', 2, '');
> select * from mv;
> v | p | c
> ---+---+---
>| a | 2
> {code}
> I think the behavior should be made consistent, if nothing else because
> querying the MV for the empty key is impossible:
> {code:java}
> cqlsh:ks> select * from mv where v = '';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14345) Empty partition keys allowed in MV, but not in normal table
[
https://issues.apache.org/jira/browse/CASSANDRA-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415529#comment-16415529
]
Duarte Nunes commented on CASSANDRA-14345:
--
It's also puzzling that I can have an empty partition key if it's multicolumn:
{code:sql}
create table t (a text, b text, c text, primary key ((a, b)))
cqlsh:ks> insert into t (a, b, c) values ('', '', '');
cqlsh:ks> select * from t;
a | b | c
---+---+---
| |
{code}
> Empty partition keys allowed in MV, but not in normal table
> ---
>
> Key: CASSANDRA-14345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14345
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
>Reporter: Duarte Nunes
>Priority: Major
> Labels: materializedviews
>
> Given the following table:
>
> {code:java}
> cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> create table t (p text, c int, v text, primary key (p));
> cqlsh> use ks;
> {code}
> The following fails:
> {code:java}
> cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
> However, MVs don't appear to have this restriction:
> {code:java}
> create materialized view mv as select * from t where v is not null and p is
> not null and c is not null primary key (v, p);
> insert into t (p, c, v) values ('a', 2, '');
> select * from mv;
> v | p | c
> ---+---+---
>| a | 2
> {code}
> I think the behavior should be made consistent, if nothing else because
> querying the MV for the empty key is impossible:
> {code:java}
> cqlsh:ks> select * from mv where v = '';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14345) Empty partition keys allowed in MV, but not in normal table
[
https://issues.apache.org/jira/browse/CASSANDRA-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duarte Nunes updated CASSANDRA-14345:
-
Description:
Given the following table:
{code:java}
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
{code}
The following fails:
{code:java}
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
However, MVs don't appear to have this restriction:
{code:java}
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
v | p | c
---+---+---
| a | 2
{code}
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
{code:java}
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
was:
Given the following table:
{code:java}
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
{code}
The following fails:
{code:java}
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
However, MVs don't appear to have this restriction:
{code:java}
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
v | p | c
---+---+---
| a | 2
{code}
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
{code:java}
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
> Empty partition keys allowed in MV, but not in normal table
> ---
>
> Key: CASSANDRA-14345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14345
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
>Reporter: Duarte Nunes
>Priority: Major
> Labels: materializedviews
>
> Given the following table:
>
> {code:java}
> cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> create table t (p text, c int, v text, primary key (p));
> cqlsh> use ks;
> {code}
> The following fails:
> {code:java}
> cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
> However, MVs don't appear to have this restriction:
> {code:java}
> create materialized view mv as select * from t where v is not null and p is
> not null and c is not null primary key (v, p);
> insert into t (p, c, v) values ('a', 2, '');
> select * from mv;
> v | p | c
> ---+---+---
>| a | 2
> {code}
> I think the behavior should be made consistent, if nothing else because
> querying the MV for the empty key is impossible:
> {code:java}
> cqlsh:ks> select * from mv where v = '';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14345) Empty partition keys allowed in MV, but not in normal table
[
https://issues.apache.org/jira/browse/CASSANDRA-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duarte Nunes updated CASSANDRA-14345:
-
Description:
Given the following table:
{code:java}
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
{code}
The following fails:
{code:java}
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
However, MVs don't appear to have this restriction:
{code:java}
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
v | p | c
---+---+---
| a | 2
{code}
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
{code:java}
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
was:
Given the following table:
{code:java}
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
{code}
The following fails:
{code:java}
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
However, MVs don't appear to have this restriction:
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
{code:java}
v | p | c
---+---+---
| a | 2
{code}
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
{code:java}
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
> Empty partition keys allowed in MV, but not in normal table
> ---
>
> Key: CASSANDRA-14345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14345
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
>Reporter: Duarte Nunes
>Priority: Major
> Labels: materializedviews
>
> Given the following table:
>
> {code:java}
> cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> create table t (p text, c int, v text, primary key (p));
> cqlsh> use ks;
> {code}
> The following fails:
> {code:java}
> cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
> However, MVs don't appear to have this restriction:
> {code:java}
> create materialized view mv as select * from t where v is not null and p is
> not null and c is not null primary key (v, p);
> insert into t (p, c, v) values ('a', 2, '');
> select * from mv;
> v | p | c
> ---+---+---
>| a | 2
> {code}
> I guess this is because an empty value can't be distinguished from null at
> the protocol level, but this distinction can be made internally.
> I think the behavior should be made consistent, if nothing else because
> querying the MV for the empty key is impossible:
> {code:java}
> cqlsh:ks> select * from mv where v = '';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14345) Empty partition keys allowed in MV, but not in normal table
Duarte Nunes created CASSANDRA-14345:
Summary: Empty partition keys allowed in MV, but not in normal
table
Key: CASSANDRA-14345
URL: https://issues.apache.org/jira/browse/CASSANDRA-14345
Project: Cassandra
Issue Type: Bug
Components: Materialized Views
Reporter: Duarte Nunes
Given the following table:
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
The following fails:
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be
empty"
However, MVs don't appear to have this restriction:
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
v | p | c
---+---+---
| a | 2
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be
empty"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14345) Empty partition keys allowed in MV, but not in normal table
[
https://issues.apache.org/jira/browse/CASSANDRA-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duarte Nunes updated CASSANDRA-14345:
-
Description:
Given the following table:
{code:java}
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
{code}
The following fails:
{code:java}
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
However, MVs don't appear to have this restriction:
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
{code:java}
v | p | c
---+---+---
| a | 2
{code}
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
{code:java}
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be
empty"{code}
was:
Given the following table:
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
The following fails:
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be
empty"
However, MVs don't appear to have this restriction:
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
v | p | c
---+---+---
| a | 2
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be
empty"
> Empty partition keys allowed in MV, but not in normal table
> ---
>
> Key: CASSANDRA-14345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14345
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
>Reporter: Duarte Nunes
>Priority: Major
> Labels: materializedviews
>
> Given the following table:
>
> {code:java}
> cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> create table t (p text, c int, v text, primary key (p));
> cqlsh> use ks;
> {code}
> The following fails:
> {code:java}
> cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
> However, MVs don't appear to have this restriction:
> create materialized view mv as select * from t where v is not null and p is
> not
> null and c is not null primary key (v, p);
> insert into t (p, c, v) values ('a', 2, '');
> select * from mv;
> {code:java}
> v | p | c
> ---+---+---
>| a | 2
> {code}
> I guess this is because an empty value can't be distinguished from null at
> the protocol level, but this distinction can be made internally.
> I think the behavior should be made consistent, if nothing else because
> querying the MV for the empty key is impossible:
> {code:java}
> cqlsh:ks> select * from mv where v = '';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be
> empty"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14345) Empty partition keys allowed in MV, but not in normal table
[
https://issues.apache.org/jira/browse/CASSANDRA-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duarte Nunes updated CASSANDRA-14345:
-
Description:
Given the following table:
{code:java}
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
{code}
The following fails:
{code:java}
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
However, MVs don't appear to have this restriction:
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
{code:java}
v | p | c
---+---+---
| a | 2
{code}
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
{code:java}
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
was:
Given the following table:
{code:java}
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
{code}
The following fails:
{code:java}
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
However, MVs don't appear to have this restriction:
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
{code:java}
v | p | c
---+---+---
| a | 2
{code}
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
{code:java}
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be
empty"{code}
> Empty partition keys allowed in MV, but not in normal table
> ---
>
> Key: CASSANDRA-14345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14345
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
>Reporter: Duarte Nunes
>Priority: Major
> Labels: materializedviews
>
> Given the following table:
>
> {code:java}
> cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> create table t (p text, c int, v text, primary key (p));
> cqlsh> use ks;
> {code}
> The following fails:
> {code:java}
> cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
> However, MVs don't appear to have this restriction:
> create materialized view mv as select * from t where v is not null and p is
> not
> null and c is not null primary key (v, p);
> insert into t (p, c, v) values ('a', 2, '');
> select * from mv;
> {code:java}
> v | p | c
> ---+---+---
>| a | 2
> {code}
> I guess this is because an empty value can't be distinguished from null at
> the protocol level, but this distinction can be made internally.
> I think the behavior should be made consistent, if nothing else because
> querying the MV for the empty key is impossible:
> {code:java}
> cqlsh:ks> select * from mv where v = '';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13762) Ensure views created during (or just before) range movements are properly built
[ https://issues.apache.org/jira/browse/CASSANDRA-13762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379277#comment-16379277 ] Duarte Nunes commented on CASSANDRA-13762: -- I think this patch assumes the base node receiving the streamed data will be paired with the same view replica as the source base node. Is this true? If so, how is that guaranteed? If not, then we might still want to send out view updates. We would need to check whether all replicas for the range in question have finished building their views, not just the source node. > Ensure views created during (or just before) range movements are properly > built > --- > > Key: CASSANDRA-13762 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13762 > Project: Cassandra > Issue Type: Bug > Components: Materialized Views >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Minor > Labels: materializedviews > Attachments: trunk-13762-dtest.png, trunk-13762-testall.png > > > CASSANDRA-13065 assumes the source node has its views built to skip running > base mutations through the write path during range movements. > It is possible that the source node has not finished building the view, or > that a new view is created during a range movement, in which case the view > may be wrongly marked as built on the destination node. > The former problem was introduced by #13065, but even before that a view > created during a range movement may not be correctly built on the destination > node because the view builder will be triggered before it has finished > streaming the source data, wrongly marking the view as built on that node. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13730) Dropping a table doesn't drop its dropped columns
[
https://issues.apache.org/jira/browse/CASSANDRA-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100728#comment-16100728
]
Duarte Nunes commented on CASSANDRA-13730:
--
Weren't the dropped columns just a map before 3.0?
> Dropping a table doesn't drop its dropped columns
> -
>
> Key: CASSANDRA-13730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13730
> Project: Cassandra
> Issue Type: Bug
>Reporter: Duarte Nunes
>Assignee: Aleksey Yeschenko
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> I'm not sure if this is intended or not, but currently a table's dropped
> columns are not dropped when the table itself is dropped:
> {noformat}
> cqlsh> create keyspace ks WITH replication={ 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 } ;
> cqlsh> use ks;
> cqlsh:ks> create table test (pk text primary key, c1 int);
> cqlsh:ks> alter table test drop c1;
> cqlsh:ks> drop table test;
> cqlsh:ks> select * from system_schema.dropped_columns where keyspace_name =
> 'ks' and table_name = 'test';
> keyspace_name | table_name | column_name | dropped_time|
> kind| type
> ---++-+-+-+--
> ks | test | c1 | 2017-07-25 17:53:47.651000+ |
> regular | int
> (1 rows)
> {noformat}
> This can have surprising consequences when creating another table with the
> same name.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13730) Dropping a table doesn't drop its dropped columns
Duarte Nunes created CASSANDRA-13730:
Summary: Dropping a table doesn't drop its dropped columns
Key: CASSANDRA-13730
URL: https://issues.apache.org/jira/browse/CASSANDRA-13730
Project: Cassandra
Issue Type: Bug
Reporter: Duarte Nunes
I'm not sure if this is intended or not, but currently a table's dropped
columns are not dropped when the table itself is dropped:
{noformat}
cqlsh> create keyspace ks WITH replication={ 'class' : 'SimpleStrategy',
'replication_factor' : 1 } ;
cqlsh> use ks;
cqlsh:ks> create table test (pk text primary key, c1 int);
cqlsh:ks> alter table test drop c1;
cqlsh:ks> drop table test;
cqlsh:ks> select * from system_schema.dropped_columns where keyspace_name =
'ks' and table_name = 'test';
keyspace_name | table_name | column_name | dropped_time|
kind| type
---++-+-+-+--
ks | test | c1 | 2017-07-25 17:53:47.651000+ |
regular | int
(1 rows)
{noformat}
This can have surprising consequences when creating another table with the same
name.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13127) Materialized Views: View row expires too soon
[
https://issues.apache.org/jira/browse/CASSANDRA-13127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002580#comment-16002580
]
Duarte Nunes commented on CASSANDRA-13127:
--
What are the TTL issues you're mentioning?
I still think it's a bug that a live row exists in the base table, but not in
the view.
> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" |
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
> p | c | ttl(v)
> ---+---+
> 0 | 0 | 7
> (1 rows)
> c | p
> ---+---
> 0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
> p | c | ttl(v)
> ---+---+
> 0 | 0 | 3
> (1 rows)
> c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry
> the TTLs are compared instead of the expiration times, but I'm not sure I'm
> getting that far ahead in the code when updating a column that's not in the
> view.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13409) Materialized Views: View cells are resurrected
[
https://issues.apache.org/jira/browse/CASSANDRA-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995796#comment-15995796
]
Duarte Nunes commented on CASSANDRA-13409:
--
I think that's about right! Unfortunately, I'm not very familiar with the 3.X
storage format, so I can't say whether it really needs to change or not.
> Materialized Views: View cells are resurrected
> --
>
> Key: CASSANDRA-13409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13409
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk@0f054fee5c:
> {code:xml}
> echo "create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};" | bin/cqlsh
> echo "create table ks.base (p int primary key, v1 int, v2 int) with
> gc_grace_seconds = 1;" | bin/cqlsh
> echo "create materialized view ks.my_view as select * from ks.base where p is
> not null and v1 is not null primary key (v1, p);" | bin/cqlsh
> echo "insert into ks.base (p, v1, v2) values (3, 1, 3) using timestamp 1;" |
> bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "delete from ks.base using timestamp 2 where p = 3;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "insert into ks.base (p, v1) values (3, 1) using timestamp 3;" |
> bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "select * from ks.my_view;" | bin/cqlsh
> v1 | p | v2
> +---+
> 1 | 3 | 3
> (1 rows)
> echo "select * from ks.base;" | bin/cqlsh
> p | v1 | v2
> ---++--
> 3 | 1 | null
> (1 rows)
> {code}
> As you can see, this incorrectly brings back cell v2=3.
> There is one definitive problem and a potential one:
> * Merging rows must be commutative. If a shadowable tombstone is applied
> after a row tombstone, it will replace that tombstone; if a row marker
> shadows the shadowable tombstone before the row containing the original data
> is applied, then any dead cells in said data will be resurrected;
> * Shadowable tombstones shouldn't compact away previous row tombstones or
> even deleted cells; if the relevant tombstones have been GCed from the base
> table, then a base table update won't carry them anymore (alongside a newer
> row marker).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13409) Materialized Views: View cells are resurrected
[
https://issues.apache.org/jira/browse/CASSANDRA-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994643#comment-15994643
]
Duarte Nunes commented on CASSANDRA-13409:
--
Why not?
You can have (base pk on p and view's pk is on v1 and p, assume flushes between
operations):
1. insert into base (p, v1, v2) values (3, 1, 3) using timestamp 1
2. update base set v2 = null where p = 3 using timestamp 2 // deletes a cell
3. update base set v1 = 2 where p = 3 using timestamp 3 // will create a
shadowable row tombstone for (v1, p) = (1, 3)
4. update base set v1 = 1 where p = 3 using timestamp 4
Here you have a deleted cell co-existing with a shadowable tombstone. The
problem is then that the view updates for 2) and 3) can be compacted together,
and the tombstone for v2 will be dropped, leaving only the shadowable row
tombstone. After the view update in 4), assuming it's done after gc grace
seconds, the row tombstone will be shadowed and the update for v2 made in 1)
will be resurrected.
You can have a similar sequence of events involving row tombstones:
1. insert into base (p, v1, v2) values (3, 1, 3) using timestamp 1
2. delete from base where p = 3 using timestamp 2 // will create a regular row
tombstone for (v1, p) = (1, 3)
3. insert into base (p, v1) values (3, 1) using timestamp 3
4. update base set v1 = 2 where p = 3 using timestamp 4 // will create a
shadowable row tombstone for (v1, p) = (1, 3)
5. update base set v1 = 1 where p = 3 using timestamp 5
Here, if the sstables with 2) and 4) are compacted together, the shadowable
tombstone will cover and remove the regular one.
The same partition can easily contain regular and shadowable tombstones, so
that should be taken into account when merging rows in memory.
> Materialized Views: View cells are resurrected
> --
>
> Key: CASSANDRA-13409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13409
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk@0f054fee5c:
> {code:xml}
> echo "create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};" | bin/cqlsh
> echo "create table ks.base (p int primary key, v1 int, v2 int) with
> gc_grace_seconds = 1;" | bin/cqlsh
> echo "create materialized view ks.my_view as select * from ks.base where p is
> not null and v1 is not null primary key (v1, p);" | bin/cqlsh
> echo "insert into ks.base (p, v1, v2) values (3, 1, 3) using timestamp 1;" |
> bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "delete from ks.base using timestamp 2 where p = 3;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "insert into ks.base (p, v1) values (3, 1) using timestamp 3;" |
> bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "select * from ks.my_view;" | bin/cqlsh
> v1 | p | v2
> +---+
> 1 | 3 | 3
> (1 rows)
> echo "select * from ks.base;" | bin/cqlsh
> p | v1 | v2
> ---++--
> 3 | 1 | null
> (1 rows)
> {code}
> As you can see, this incorrectly brings back cell v2=3.
> There is one definitive problem and a potential one:
> * Merging rows must be commutative. If a shadowable tombstone is applied
> after a row tombstone, it will replace that tombstone; if a row marker
> shadows the shadowable tombstone before the row containing the original data
> is applied, then any dead cells in said data will be resurrected;
> * Shadowable tombstones shouldn't compact away previous row tombstones or
> even deleted cells; if the relevant tombstones have been GCed from the base
> table, then a base table update won't carry them anymore (alongside a newer
> row marker).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13409) Materialized Views: View cells are resurrected
[
https://issues.apache.org/jira/browse/CASSANDRA-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duarte Nunes updated CASSANDRA-13409:
-
Summary: Materialized Views: View cells are resurrected (was: Materialized
Views: View cells is resurrected)
> Materialized Views: View cells are resurrected
> --
>
> Key: CASSANDRA-13409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13409
> Project: Cassandra
> Issue Type: Bug
>Reporter: Duarte Nunes
>
> Consider the following commands, ran against trunk@0f054fee5c:
> {code:xml}
> echo "create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};" | bin/cqlsh
> echo "create table ks.base (p int primary key, v1 int, v2 int) with
> gc_grace_seconds = 1;" | bin/cqlsh
> echo "create materialized view ks.my_view as select * from ks.base where p is
> not null and v1 is not null primary key (v1, p);" | bin/cqlsh
> echo "insert into ks.base (p, v1, v2) values (3, 1, 3) using timestamp 1;" |
> bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "delete from ks.base using timestamp 2 where p = 3;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "insert into ks.base (p, v1) values (3, 1) using timestamp 3;" |
> bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "select * from ks.my_view;" | bin/cqlsh
> v1 | p | v2
> +---+
> 1 | 3 | 3
> (1 rows)
> echo "select * from ks.base;" | bin/cqlsh
> p | v1 | v2
> ---++--
> 3 | 1 | null
> (1 rows)
> {code}
> As you can see, this incorrectly brings back cell v2=3.
> There is one definitive problem and a potential one:
> * Merging rows must be commutative. If a shadowable tombstone is applied
> after a row tombstone, it will replace that tombstone; if a row marker
> shadows the shadowable tombstone before the row containing the original data
> is applied, then any dead cells in said data will be resurrected;
> * Shadowable tombstones shouldn't compact away previous row tombstones or
> even deleted cells; if the relevant tombstones have been GCed from the base
> table, then a base table update won't carry them anymore (alongside a newer
> row marker).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CASSANDRA-13409) Materialized Views: View cells is resurrected
Duarte Nunes created CASSANDRA-13409:
Summary: Materialized Views: View cells is resurrected
Key: CASSANDRA-13409
URL: https://issues.apache.org/jira/browse/CASSANDRA-13409
Project: Cassandra
Issue Type: Bug
Reporter: Duarte Nunes
Consider the following commands, ran against trunk@0f054fee5c:
{code:xml}
echo "create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};" | bin/cqlsh
echo "create table ks.base (p int primary key, v1 int, v2 int) with
gc_grace_seconds = 1;" | bin/cqlsh
echo "create materialized view ks.my_view as select * from ks.base where p is
not null and v1 is not null primary key (v1, p);" | bin/cqlsh
echo "insert into ks.base (p, v1, v2) values (3, 1, 3) using timestamp 1;" |
bin/cqlsh
bin/nodetool flush ks my_view base
echo "delete from ks.base using timestamp 2 where p = 3;" | bin/cqlsh
bin/nodetool flush ks my_view base
echo "insert into ks.base (p, v1) values (3, 1) using timestamp 3;" | bin/cqlsh
bin/nodetool flush ks my_view base
echo "select * from ks.my_view;" | bin/cqlsh
v1 | p | v2
+---+
1 | 3 | 3
(1 rows)
echo "select * from ks.base;" | bin/cqlsh
p | v1 | v2
---++--
3 | 1 | null
(1 rows)
{code}
As you can see, this incorrectly brings back cell v2=3.
There is one definitive problem and a potential one:
* Merging rows must be commutative. If a shadowable tombstone is applied after
a row tombstone, it will replace that tombstone; if a row marker shadows the
shadowable tombstone before the row containing the original data is applied,
then any dead cells in said data will be resurrected;
* Shadowable tombstones shouldn't compact away previous row tombstones or even
deleted cells; if the relevant tombstones have been GCed from the base table,
then a base table update won't carry them anymore (alongside a newer row
marker).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13127) Materialized Views: View row expires too soon
[
https://issues.apache.org/jira/browse/CASSANDRA-13127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839597#comment-15839597
]
Duarte Nunes commented on CASSANDRA-13127:
--
I think that the behaviour for an {{UPDATE}} should match that of an
{{INSERT}}, since the latter is probably too late to change.
So, I think a view row's lifetime should be tied to the base row's lifetime,
and that's kind what the code tries to do (the view row liveness can be set to
match that of a column not in the view).
If an operation extends the lifetime of a base row, the corresponding views
should be updated. Similarly, if an update resurrects a base row, the view row
should also be resurrected even if it doesn't include the particular column
that triggered it.
> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
> Issue Type: Bug
>Reporter: Duarte Nunes
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" |
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
> p | c | ttl(v)
> ---+---+
> 0 | 0 | 7
> (1 rows)
> c | p
> ---+---
> 0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
> p | c | ttl(v)
> ---+---+
> 0 | 0 | 3
> (1 rows)
> c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry
> the TTLs are compared instead of the expiration times, but I'm not sure I'm
> getting that far ahead in the code when updating a column that's not in the
> view.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-13127) Materialized Views: View row expires too soon
Duarte Nunes created CASSANDRA-13127:
Summary: Materialized Views: View row expires too soon
Key: CASSANDRA-13127
URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
Project: Cassandra
Issue Type: Bug
Reporter: Duarte Nunes
Consider the following commands, ran against trunk:
{code}
echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" |
bin/cqlsh
echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT
NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
# wait for row liveness to get closer to expiration
sleep 6;
echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
p | c | ttl(v)
---+---+
0 | 0 | 7
(1 rows)
c | p
---+---
0 | 0
(1 rows)
# wait for row liveness to expire
sleep 4;
echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
p | c | ttl(v)
---+---+
0 | 0 | 3
(1 rows)
c | p
---+---
(0 rows)
{code}
Notice how the view row is removed even though the base row is still live. I
would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry
the TTLs are compared instead of the expiration times, but I'm not sure I'm
getting that far ahead in the code when updating a column that's not in the
view.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
