[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645890#comment-14645890
]
Aleksey Yeschenko commented on CASSANDRA-6477:
----------------------------------------------
I know we already have CASSANDRA-9736, but in the meantime {{ALTER TABLE}}
should not be allowed to alter MVs (don't want it to be accidentally forgotten).
Instead of having a {{ConcurrentHashSet}} in {{Schema}} (named
{{materializedViewList}}, for some reason), MVness of a table should be a
boolean flag, or, better, an enum, in {{CFMetaData}}.
There seems to be no validation on Thrift side against modifying a view
directly (think {{CassandraServer}}).
It's possible to create an index, or add a trigger, to an MV. I think the
latter would just break, and not sure if we want to ever support the former.
Security is not handled completely properly. {{CREATE MATERIALIZED VIEW}} is
requiring {{SELECT}} on the base table. It shouldn't. We should be checking for
{{SELECT}} permission against the base table every query against MVs (a check
on {{CREATE}} is a one-time check, and then permission can go away at any
time). May also look into new permissions altogether for view DDL /cc [~beobal]
We need to think where MVs are on the hierarchy. Are they on the same level as
secondary indexes, or on the same level as other tables, UDTs, UDFs, and UDAs?
In the latter case, we need new events for the native protocol.
It would be my strong preference that MVs do not reuse {{system_schema.tables}}
to store their metadata, even if it means some duplication. (for schema code,
after the next CASSANDRA-9712 comment that will factor-out {{TableParams}}, the
duplication will be less of an issue). The way it's currently done, with a
'link' table, I'm not a fan of. One table with those two merged should be
enough.
We are committed to supporting proper {{WHERE}} clause in the future (and
CASSANDRA-9778). I expect the necessary schema to support it to be in 3.0 GA,
for forward compatibility. Altering schema tables is not exactly trivial, and
may force us to have to wait until 4.0 for those features.
> 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 alpha 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)
