cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Greaves (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13657) Materialized Views: Index MV on TTL'ed column produces orphanized view entry if another column keeps entry live
Date Thu, 13 Jul 2017 02:36:00 GMT

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

Kurt Greaves commented on CASSANDRA-13657:
------------------------------------------

[~fsander] 
bq. From my understanding that is not possible, since all PK parts must be NOT NULL
That is correct, going back to the original implementation there was a lot of discussion about
this and it was decided to enforce all PK parts to be NOT NULL, to simplify the implementation
for 3.0. However at the time it was never confirmed whether it would be a strict requirement
for the future. Hinted at as a hard problem to solve, but not ruled out entirely. See [original|https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14627670&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14627670]
ticket and comments surrounding it: 

My concern is that tying MV "components" to base "components" makes it more difficult to lift
the {{IS NOT NULL}} requirement. That requirement might be perfectly fine, but I think a decision
needs to be made beforehand if that is the path we'll go down with MV's.

This really applies in general to MV bugs/existing tickets however (and is probably not the
only issue), as it likely has an impact on how we fix all of them (i.e do we cram more "features"
in to fix the bugs, or do we aim to re-write this stuff to make Cassandra more view-friendly).

bq. The way I see it, a view-row's liveness is actually different from an ordinary row's liveness.
So, it makes sense to have code representing that difference, instead of squeezing the new
definition into the old mechanism and constantly having to patch stuff left and right.
To clarify - you're totally correct, however I'm more asking the question of "do we want that
to always be the case?". Personally I wouldn't mind as it simplifies things (especially this
case), but I'm certainly no authority on the matter.

Anyway, it would be good to get more people in on the discussion (and hopefully some of the
original developers) so I'll ping the ML.

> Materialized Views: Index MV on TTL'ed column produces orphanized view entry if another
column keeps entry live
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-13657
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13657
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Materialized Views
>            Reporter: Fridtjof Sander
>            Assignee: Krishna Dattu Koneru
>              Labels: materializedviews, ttl
>
> {noformat}
> CREATE TABLE t (k int, a int, b int, PRIMARY KEY (k));
> CREATE MATERIALIZED VIEW mv AS SELECT * FROM t WHERE k IS NOT NULL AND a IS NOT NULL
PRIMARY KEY (a, k);
> INSERT INTO t (k) VALUES (1);
> UPDATE t USING TTL 5 SET a = 10 WHERE k = 1;
> UPDATE t SET b = 100 WHERE k = 1;
> SELECT * from t; SELECT * from mv;
>  k | a  | b
> ---+----+-----
>  1 | 10 | 100
> (1 rows)
>  a  | k | b
> ----+---+-----
>  10 | 1 | 100
> (1 rows)
> -- 5 seconds later
> SELECT * from t; SELECT * from mv;
>  k | a    | b
> ---+------+-----
>  1 | null | 100
> (1 rows)
>  a  | k | b
> ----+---+-----
>  10 | 1 | 100
> (1 rows)
> -- that view entry's liveness-info is (probably) dead, but the entry is kept alive by
b=100
> DELETE b FROM t WHERE k=1;
> SELECT * from t; SELECT * from mv;
>  k | a    | b
> ---+------+------
>  1 | null | null
> (1 rows)
>  a  | k | b
> ----+---+-----
>  10 | 1 | 100
> (1 rows)
> DELETE FROM t WHERE k=1;
> cqlsh:test> SELECT * from t; SELECT * from mv;
>  k | a | b
> ---+---+---
> (0 rows)
>  a  | k | b
> ----+---+-----
>  10 | 1 | 100
> (1 rows)
> -- deleting the base-entry doesn't help, because the view-key can not be constructed
anymore (a=10 already expired)
> {noformat}
> The problem here is that although the view-entry's liveness-info (probably) expired correctly
a regular column (`b`) keeps the view-entry live. It should have disappeared since it's indexed
column (`a`) expired in the corresponding base-row. This is pretty severe, since that view-entry
is now orphanized.



--
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


Mime
View raw message