I am cool with pluggability and making things easier to test; my main
comment for this work is that we must also define semantics around the APIs
and can't just create interfaces. Simple example of this is CASSANDRA-17058
<https://issues.apache.org/jira/browse/CASSANDRA-17058> (linked from the
CEP), i have made up my own interface below to explain.
interface Membership {
...
void addMember(AddressAndPort address);
}
This interface is extremely problematic as expectations are not clearly
defined. Right now our membership changes are not atomic and depend on
propagation delay (and this is even in the same JVM), so in one
implementation this may be atomic, and we test against atomic (as
thats much simpler in testing), but then the actually implementation we
ship isn't... aka 0 of our tests using these mocks matter; Also, this
doesn't work if we want to move to a thread-per-core architecture in the
future as the concurrency isn't defined.
A simple way I think about pluggability, we should have the interfaces and
clearly define expectations around them, we then write our tests against
such interfaces and then swap in the implementations to make sure that they
comply; this is a massive effort for each interface, but has good long term
benefits.
On Mon, Oct 25, 2021 at 2:39 AM bened...@apache.org <bened...@apache.org>
wrote:
> Hi Jeremiah,
>
> My personal view is that work to modularise the codebase should be tied to
> specific use cases. If improved testing is the purpose of this work, I
> think it would help to include those improved tests that you plan to
> support as goals for the CEP.
>
> If on the other hand some of this work is primarily intended to enable
> certain features, I personally think it would be preferable to tie them to
> those features - perhaps with their own CEP?
>
>
> From: Jeremiah Jordan <jeremiah.jor...@gmail.com>
> Date: Friday, 22 October 2021 at 16:24
> To: Cassandra DEV <dev@cassandra.apache.org>
> Subject: [DISCUSS] CEP-18: Improving Modularity
> Hi All,
> As has been seen with the work already started in CEP-10, increasing the
> modularity of our subsystems can improve their testability, and also the
> ability to try new implementations without breaking things.
>
> Our team has been working on doing this and CEP-18 has been created to
> propose adding more modularity to a few different subsystems.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-18%3A+Improving+Modularity
>
> CASSANDRA-17044 has already been created for Schema Storage changes related
> to this work and more JIRAs and PRs are to follow for the other subsystems
> proposed in the CEP.
>
> Thanks,
> -Jeremiah Jordan
>
