[
https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431259#comment-17431259
]
Alex Petrov edited comment on CASSANDRA-17044 at 10/21/21, 9:04 AM:
--------------------------------------------------------------------
[~jlewandowski] could you give some background on how you're planning to use /
plug in etcd? Some changes are just not fully obvious without this information.
I really like strides towards encapsulation, just want to understand where some
of the things coming from.
The main entrypoints seem to be {{SchemaUpdateHandler}}, am still curious about
your design, since we already abstract {{SchemaProvider}}, which could
theoretically give quite a lot of flexibility, especially given
{{SchemaChangeNotifier}} and {{SchemaUpdateHandler}} are initialised within the
schema itself.
I think all these questions arise because I'm trying to imagine an
implementation of strongly consistent schema from these interfaces, so it could
help if you could give more information about your etcd idea/implementation,
since we definitely want to have an in-tree implementation using internal Paxos
(see [CASSANDRA-10699]), and should consider how this patch would allow for
both implementations to coexist peacefully, since as I would imagine majority
of users would prefer a consistent schema implementation that does not have
external dependencies, but until this happens, this patch could be a step in
that direction.
I think the interface we should support may completely hide Schema storage
behind the Provider interface, and updates can be propagated through the
methods available on this interface. Local updates can/shall be applied right
away, while global ones shall go through the consistent log impl.
[~paulo] just to make sure, there's no explicit entity that is called
{{Schema}} unlike all other examples. There's no {{HintsManager}}, but it's
likely that you mean {{HintsStore}}, but there are also {{Hint}} s. Similarly,
there are {{CompactionStrateg}} ies and there is their manager. I do not see
how this makes the codebase more consistent (if only because we use the word
{{Manager}} more), or more meaningful. I'm sure there never was any confusion
about what {{Schema}} class represents. I agree with what Benedict has
mentioned above with regard the fact that {{XManager}} is well used with
countable nouns, where it makes it clear that it manager multiple instances of
{{X}}.
was (Author: ifesdjeen):
[~jlewandowski] could you give some background on how you're planning to use /
plug in etcd? Some changes are just not fully obvious without this information.
I really like strides towards encapsulation, just want to understand where some
of the things coming from. [UPD] I realise that the main entrypoint is
{{SchemaUpdateHandler}}, but am still curious about your design.
[~paulo] just to make sure, there's no explicit entity that is called
{{Schema}} unlike all other examples. There's no {{HintsManager}}, but it's
likely that you mean {{HintsStore}}, but there are also {{Hint}} s. Similarly,
there are {{CompactionStrateg}} ies and there is their manager. I do not see
how this makes the codebase more consistent (if only because we use the word
{{Manager}} more), or more meaningful. I'm sure there never was any confusion
about what {{Schema}} class represents. I agree with what Benedict has
mentioned above with regard the fact that {{XManager}} is well used with
countable nouns, where it makes it clear that it manager multiple instances of
{{X}}.
> 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]
