[ 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