[
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17432310#comment-17432310
]
Jacek Lewandowski commented on CASSANDRA-17044:
-----------------------------------------------
[~ifesdjeen] the current {{Schema}} implementation does several things - it
maintains the local copy of keyspaces metadata, the keyspace instances, table
metadata references cache and schema change listeners. Performing an update on
a schema, say dropping a table requires several things to happen, in particular:
- we need to remove it from keyspace metadata
- we need to tear down related CFS and remove it from the keyspace instance
- we need to remove the table metadata reference
- we need to send the notifications
- we need to store the updates and sync with other nodes
- we need to update the version
Some of those operations are unrelated to the way how we store the schema. In
particular, managing CFSs, handling notifications or table metadata references
is common for whichever schema storage mechanism we use.
Therefore I've extracted {{SchemaUpdateHandler}} interface which serves just
for storage and sync of the schema. That is, the current {{Schema}} (or
{{SchemaManager}}) only needs to call a method on that interface to request the
schema change. On the other hand, the factory of update handler takes the
callback function as an argument. This callback is called whenever the schema
gets changed, regardless which party initiated the change. In other words, the
caller ({{Schema}}) can only request schema changes and react to the changes
that were applied on the schema, wherever that schema is.
There are obviously some issues which remains unfixed as I was not aiming to
fix them - there can be a failure when applying changes locally, so the changes
can be applied only partially and there is no explicit recovery mechanism (say
we fail to tear down CFS when dropping a table). But this does not affect
changes to the schema itself as we handle local application as a followup
action.
Does it clarify things a bit?
> Refactor schema management to allow for schema source pluggability
> ------------------------------------------------------------------
>
> Key: CASSANDRA-17044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17044
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
>
> The idea is decompose `Schema` into separate entities responsible for
> different things. In particular extract what is related to schema storage and
> synchronization into a separate class so that it is possible to create an
> extension point there and store schema in a different way than
> `system_schema` keyspace, for example in etcd.
> This would also simplify the logic and reduce the number of special cases,
> make all the things more testable and the logic of internal classes
> encapsulated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
