[
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431206#comment-17431206
]
Benedict Elliott Smith edited comment on CASSANDRA-17044 at 10/20/21, 12:58 PM:
--------------------------------------------------------------------------------
bq. Overall, I'm -0 on the change, I just do not see addition of "manager" in
the name as an improvement.
I agree here, and in general we should always prefer shorter names if there is
no improved meaning. "Manager" is one of those words that often means nothing
by itself. It's usually added only to countable nouns that have concrete
implementations themselves, such as CommitLogSegmentManager (which manages
CommitLogSegments). In most other situation it is a bit like "Data" - it offers
no additional context for the reader, only pollutes their screen making each
line of code involving it harder to parse.
was (Author: benedict):
bq. Overall, I'm -0 on the change, I just do not see addition of "manager" in
the name as an improvement.
I agree here, and in general we should always prefer shorter names if there is
no improved meaning from longer names. Manager is one of those words that often
means nothing by itself. It's usually added only to countable nouns that have
concrete implementations themselves, such as CommitLogSegmentManager (which
manages CommitLogSegments). In most other situation it is a bit like "Data" -
it offers no additional context for the reader, only pollutes their screen
making each line of code involving it harder to parse.
> 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]
