[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14626604#comment-14626604
]
Carl Yeksigian commented on CASSANDRA-6477:
-------------------------------------------
[~iamaleksey]: I added support to allow for changing the table options with
{{CREATE MATERIALIZED VIEW}}, so it is possible to set those options when
creating the view.
[~slebresne]:
bq. Is it how this currently work?
Yes, this is how it currently works; if we have any NULLs in the view primary
key, we do not insert that into the view.
Changing this would also imply that
{code:sql}
INSERT INTO (k,t) VALUES (0, 0);
{code}
would create a row in the view as well for (0, null, 0).
bq. 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.
It works this was under the assumption that we don't have to represent the null
columns which are introduced when the current ttl'd columns expire; if that
changes, we'll have to redo all of the current ttl work, which is fine as long
as we have both a clear idea of the work involved to introduce this, and a real
use case we are trying to support.
Overall, I'd be more surprised that a materialized view is including rows for
values that were never set, or which were specifically deleted, not that it
isn't including those values.
> 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)
