> On Oct 25, 2021, at 1:22 PM, Jeremiah D Jordan wrote:
>
> The currently proposed changes in CEP-18 should all include improved test
> coverage of the modules in question. We have been developing them all with a
> requirement that all changes have at least %80 code coverage from sonar cloud
Yes, those explanations sound very reasonable to me as well and I'll push the
implementation soon.
Thank you guys
On 2021/10/26 18:21:44, Joshua McKenzie wrote:
> +1 to Benedict's perspective here. Supporting both sstable ID paradigms
> should be relatively trivial and low cost to maintain goi
> we should probably also focus on getting rid of what is obsolete and simplify
> and unify the codebase where it smells.
Agreed. Lots of the codebase has had a spring clean over the past couple of
years, but lots hasn’t. Some areas are very long in the tooth and could do with
some heavy prunin
> The only sub-proposal I’m particularly unsure about is 17059, which doesn’t
> seem to increase modularity at all. It looks to be a kind of plugin hook, and
> IMO should definitely be addressed separately. Perhaps a simple DISCUSS
> thread and its Jira will suffice?
Ok. I will remove that one
I am all for good extensibility / interfaces and so on, however I am
afraid that this might actually break a lot of things if enough
attention is not paid. For example, over all these years, the
community around Cassandra tooling is somehow used to the "mess",
placing one fat jar to the class path
> I'm not particularly sympathetic to the concerns about friction on making
> changes to internal API's since modern IDE tooling makes this a trivial
> exercise
We’re getting abstract here, so this isn’t a rebuttal or even tied to strongly
this particularly discussion, but to express my point m
+1 to Benedict's perspective here. Supporting both sstable ID paradigms
should be relatively trivial and low cost to maintain going forward.
On Tue, Oct 26, 2021 at 7:54 AM bened...@apache.org
wrote:
> I think it is probably acceptable to prevent downgrades once a new feature
> is enabled, as th
>
> To me having some defined interfaces for interacting with different
> sections of the code is a huge boon for improving developer productivity
> going forward in the project. Every place where we can reduce the amount
> of code reaching inside another module to get at a random internal class i
I think it is probably acceptable to prevent downgrades once a new feature is
enabled, as the exposure risk is limited to that one feature. The user can test
the new version to ensure everything else works satisfactorily before
committing to this one feature.
A downgrade tool would also be poss
The user will be able to test the new feature in a testing environment
and not push the changes to their production environment if they are not
satisfied.
On 26/10/2021 12:00, Jacek Lewandowski wrote:
Though, the user is unable to test the new feature without enabling it. And
when it is enable
Though, the user is unable to test the new feature without enabling it. And
when it is enabled, the user is unable to revert it.
- - -- --- - -
Jacek Lewandowski
On Tue, Oct 26, 2021 at 12:54 PM Bowen Song wrote:
> Personally, I would prefer a transition period in whic
Personally, I would prefer a transition period in which the new feature
is not enabled by default. This not only makes version upgrading easier,
it also allows the user to stay on the old behaviour if they experience
any issue with the new feature (e.g.: bugs in the new feature, or edge
use cas
Hi,
In short, we are discussing UUID based sstable generation identifiers in
https://issues.apache.org/jira/browse/CASSANDRA-17048.
The question which somehow hold us is support for downgrading. Long story
short, when we generate new sstables with uuid based ids, they are not readable
by olde
13 matches
Mail list logo
