Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 12 Jul 2017 10:25:00 +0000 (UTC)
From: "ZhaoYang (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13035319.1484597939000.227050.1499855100364@Atlassian.JIRA>
In-Reply-To: <JIRA.13035319.1484597939000@Atlassian.JIRA>
References: <JIRA.13035319.1484597939000@Atlassian.JIRA> <JIRA.13035319.1484597939211@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (CASSANDRA-13127) Materialized Views: View
 row expires too soon
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 12 Jul 2017 13:48:54 -0000


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

ZhaoYang edited comment on CASSANDRA-13127 at 7/12/17 10:24 AM:
----------------------------------------------------------------

{{when updating base's columns which are not used in view.}} is about whether we should consider `Update semantic the same as Insert`. (for now it's not the same. update-statement has no primary key liveness info. pk's liveness of update-statement is depending on liveness of normal columns)

eg. current semantic/behavior:   
{quote}
base table: create table ks.base (p int, c int, v int, primary key (p, c))
view table:  select p,c from ks.base ... primary key (c, p)
an update query on base table normal column {{v}} will not generate any rows..
a delete query on base table normal column {{v}} will remove the base row.
{quote}

imo, to avoid user confusion, it's better to keep view matched with base regardless semantic of update..(the current patch is not general enough to cover all such cases yet)
[~tjake][~slebresne] what do you think?


was (Author: jasonstack):
{{when updating base's columns which are not used in view.}} is about whether we should consider `Update semantic the same as Insert`. (for now it's not the same. update-statement has no primary key liveness info. pk's liveness of update-statement is depending on liveness of normal columns)

eg.   
{quote}
base table: create table ks.base (p int, c int, v int, primary key (p, c))
view table:  select p,c from ks.base ... primary key (c, p)
an update query on base table normal column {{v}} will not generate any rows..
a delete query on base table normal column {{v}} will remove the base row.
{quote}

imo, to avoid user confusion, it's better to keep view matched with base regardless semantic of update..(the current patch is not general enough to cover all such cases yet)
[~tjake][~slebresne] what do you think?


> 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
>            Assignee: ZhaoYang
>
> 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.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org