[
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433683#comment-17433683
]
Benedict Elliott Smith commented on CASSANDRA-17044:
----------------------------------------------------
bq. Even though I generally like that SchemaChangeListener is now an interface
rather than abstract class, I’m concerned about potential users who might have
relied on it being implemented the way it was
My personal view on internal APIs like this is that we shouldn't offer any
guarantees about backwards compatibility. In this instance if it's easy to
maintain then great, but we should not set an expectation of this. The main
goal should always be what is useful for Cassandra today. Just my 2¢.
> 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: [email protected]
For additional commands, e-mail: [email protected]
