[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14626545#comment-14626545
]
Sylvain Lebresne commented on CASSANDRA-6477:
---------------------------------------------
Ok, let me back up a minute here. If I understand correctly, the current
semantic is that if a view has a non-PK column from the base table, then the MV
only has an entry if that non-PK column is not null? In other words, given:
{noformat}
CREATE TABLE t (k int, t int, v int, PRIMARY KEY (k, t));
CREATE MATERIALIZED VIEW v AS SELECT * FROM t PRIMARY KEY (t, v, k);
INSERT INTO t (k, t, v) VALUES (0, 0, 0) USING TTL 1000;
UPDATE t SET v = null WHERE k = 0 AND t = 0;
{noformat}
If you do:
{noformat}
SELECT * FROM v;
{noformat}
you get no results, even though the view was created with a {{SELECT *}} and
there _is_ a row in the base table. Is it how this currently work?
Perhaps more importantly, is it how we want it to work?
That is, doesn't it feel a bit inconsistent not to have any entry in the view?
That typically mean that if you query the view to find how many rows have {{t
== 0}}, you won't have an accurate answer in particular. Wouldn't it be better
to get:
{noformat}
SELECT * FROM v;
t | v | k
-------------
0 | null | 0
{noformat}
bq. Because that is the only column which is supported, we TTL the row in the
view so that it is taken care of the same as the base TTL.
Assuming we are fine with the semantic of "the view only has a row if the base
class has a row *and* none of the non-PK columns of the base class that are in
the MV Pk are null" (which I'm not sure I am, and is an important decision for
sure), then I think we've be fine with more than one column on that front by
simply using the min TTL of all the columns.
> Materialized Views (was: Global Indexes)
> ----------------------------------------
>
> Key: CASSANDRA-6477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6477
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Assignee: Carl Yeksigian
> Labels: cql
> Fix For: 3.0 beta 1
>
> Attachments: test-view-data.sh, users.yaml
>
>
> Local indexes are suitable for low-cardinality data, where spreading the
> index across the cluster is a Good Thing. However, for high-cardinality
> data, local indexes require querying most nodes in the cluster even if only a
> handful of rows is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
