[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14626685#comment-14626685
]
Sylvain Lebresne commented on CASSANDRA-6477:
---------------------------------------------
{quote}
However, if we have the view also have a null for the first row, so it would be
(0, null, 0), wouldn't we also expect to see a row for (1, null, 1)?
The fact that a cell was non-null and is now null shouldn't really have any
different behavior than if it was null from the start.
{quote}
Certainly. Having a column {{null}} is in CQL by definition the equivalent of
the column not having value. I'm not in any way suggesting we should make a
difference here.
bq. That is, the MV will have the same columns in its primary key as the base
table's, but with different partition keys and different orders for clustering
columns. I could be wrong, but that seems like the biggest use case. And in
that use case the keys are all non-null.
The question is if this should be the *only* supported case. If you read the
comments above, some people strongly disagree. So we're debating how it should
work when that's not the case and how to support it. Everybody agrees the case
you're describing is the easy case.
> 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)
