[ 
https://issues.apache.org/jira/browse/CASSANDRA-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Holmberg updated CASSANDRA-10328:
--------------------------------------
    Description: 
I'm seeing inconsistent event delivery when it comes to dropping materialized 
views (when compared to tables or indexes).

For example, create/drop/alter for a table:
{code}
cassandra@cqlsh:test> create TABLE t (k int PRIMARY KEY , v int);
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'CREATED', 'target_type': 
u'TABLE', u'table': u't'}, stream_id=-1)>
cassandra@cqlsh:test> alter TABLE t add v1 int;
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'TABLE', u'table': u't'}, stream_id=-1)>
cassandra@cqlsh:test> drop TABLE t;
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'DROPPED', 'target_type': 
u'TABLE', u'table': u't'}, stream_id=-1)>
{code}

And for a view:
{code}
cassandra@cqlsh:test> create MATERIALIZED VIEW mv as select * from scores WHERE 
game IS NOT NULL AND score IS NOT NULL AND user IS NOT NULL AND year IS NOT 
NULL AND month IS NOT NULL AND day IS NOT NULL        PRIMARY KEY (game, user, 
year, month, day, score)        WITH CLUSTERING ORDER BY (score desc);
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'CREATED', 'target_type': 
u'TABLE', u'table': u'mv'}, stream_id=-1)>
cassandra@cqlsh:test> alter materialized view mv with min_index_interval = 100;
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'TABLE', u'table': u'mv'}, stream_id=-1)>
cassandra@cqlsh:test> drop MATERIALIZED VIEW mv;
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
{code}

The latter sequence is missing a table update event, meaning clients cannot 
tell that a view was dropped.
This is on a [branch 
in-progress|https://github.com/iamaleksey/cassandra/commits/9921-3.0] for 
CASSANDRA-9921

As a side note, I also believe they keyspace update events are unnecessary in 
both scenarios. To my knowledge, drivers only use these events to refresh meta 
on the keyspace definition itself, not the entities it contains. Please let me 
know if this is worthy of discussion or a distinct ticket.

  was:
I'm seeing inconsistent event delivery when it comes to dropping materialized 
views (when compared to tables or indexes).

For example, create/drop/alter for a table:
{code}
cassandra@cqlsh:test> create TABLE t (k int PRIMARY KEY , v int);
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'CREATED', 'target_type': 
u'TABLE', u'table': u't'}, stream_id=-1)>
cassandra@cqlsh:test> alter TABLE t add v1 int;
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'TABLE', u'table': u't'}, stream_id=-1)>
cassandra@cqlsh:test> drop TABLE t;
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'DROPPED', 'target_type': 
u'TABLE', u'table': u't'}, stream_id=-1)>
{code}

And for a view:
{code}
cassandra@cqlsh:test> create MATERIALIZED VIEW mv as select * from scores WHERE 
game IS NOT NULL AND score IS NOT NULL AND user IS NOT NULL AND year IS NOT 
NULL AND month IS NOT NULL AND day IS NOT NULL        PRIMARY KEY (game, user, 
year, month, day, score)        WITH CLUSTERING ORDER BY (score desc);
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'CREATED', 'target_type': 
u'TABLE', u'table': u'mv'}, stream_id=-1)>
cassandra@cqlsh:test> alter materialized view all with min_index_interval = 100;
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'TABLE', u'table': u'all'}, stream_id=-1)>
cassandra@cqlsh:test> drop MATERIALIZED VIEW mv;
<EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
u'KEYSPACE'}, stream_id=-1)>
{code}

The latter sequence is missing a table update event, meaning clients cannot 
tell that a view was dropped.
This is on a [branch 
in-progress|https://github.com/iamaleksey/cassandra/commits/9921-3.0] for 
CASSANDRA-9921

As a side note, I also believe they keyspace update events are unnecessary in 
both scenarios. To my knowledge, drivers only use these events to refresh meta 
on the keyspace definition itself, not the entities it contains. Please let me 
know if this is worthy of discussion or a distinct ticket.


> Inconsistent Schema Change Events Between Table and View
> --------------------------------------------------------
>
>                 Key: CASSANDRA-10328
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10328
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Adam Holmberg
>
> I'm seeing inconsistent event delivery when it comes to dropping materialized 
> views (when compared to tables or indexes).
> For example, create/drop/alter for a table:
> {code}
> cassandra@cqlsh:test> create TABLE t (k int PRIMARY KEY , v int);
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
> u'KEYSPACE'}, stream_id=-1)>
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'CREATED', 'target_type': 
> u'TABLE', u'table': u't'}, stream_id=-1)>
> cassandra@cqlsh:test> alter TABLE t add v1 int;
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
> u'KEYSPACE'}, stream_id=-1)>
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
> u'TABLE', u'table': u't'}, stream_id=-1)>
> cassandra@cqlsh:test> drop TABLE t;
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
> u'KEYSPACE'}, stream_id=-1)>
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'DROPPED', 'target_type': 
> u'TABLE', u'table': u't'}, stream_id=-1)>
> {code}
> And for a view:
> {code}
> cassandra@cqlsh:test> create MATERIALIZED VIEW mv as select * from scores 
> WHERE game IS NOT NULL AND score IS NOT NULL AND user IS NOT NULL AND year IS 
> NOT NULL AND month IS NOT NULL AND day IS NOT NULL        PRIMARY KEY (game, 
> user, year, month, day, score)        WITH CLUSTERING ORDER BY (score desc);
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
> u'KEYSPACE'}, stream_id=-1)>
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'CREATED', 'target_type': 
> u'TABLE', u'table': u'mv'}, stream_id=-1)>
> cassandra@cqlsh:test> alter materialized view mv with min_index_interval = 
> 100;
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
> u'KEYSPACE'}, stream_id=-1)>
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
> u'TABLE', u'table': u'mv'}, stream_id=-1)>
> cassandra@cqlsh:test> drop MATERIALIZED VIEW mv;
> <EventMessage(event_type=u'SCHEMA_CHANGE', trace_id=None, 
> event_args={'keyspace': u'test', 'change_type': u'UPDATED', 'target_type': 
> u'KEYSPACE'}, stream_id=-1)>
> {code}
> The latter sequence is missing a table update event, meaning clients cannot 
> tell that a view was dropped.
> This is on a [branch 
> in-progress|https://github.com/iamaleksey/cassandra/commits/9921-3.0] for 
> CASSANDRA-9921
> As a side note, I also believe they keyspace update events are unnecessary in 
> both scenarios. To my knowledge, drivers only use these events to refresh 
> meta on the keyspace definition itself, not the entities it contains. Please 
> let me know if this is worthy of discussion or a distinct ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to