Re: [DISCUSS] CEP-7 Storage Attached Index

> > We are looking forward to the community's feedback and suggestions. > What comes immediately to mind is testing requirements. It has been mentioned already that the project's testability and QA guidelines are inadequate to successfully introduce new features and refactorings to the codebase.

Re: [DISCUSS] CEP-7 Storage Attached Index

Mick thanks for your questions. > During the 4.0 beta phase this was intended to be addressed, i.e.> defining more specific QA guidelines for 4.0-rc. This would be an important > step towards QA guidelines for all changes and CEPs post-4.0. Agreed, I think CASSANDRA-15536

Re: [DISCUSS] CEP-7 Storage Attached Index

Thank you Zhao Yang for starting this topic After reading the short design doc, I have a few questions 1) SASI was pretty inefficient indexing wide partitions because the index structure only retains the partition token, not the clustering colums. As per design doc SAI has row id mapping to parti

Re: [DISCUSS] CEP-7 Storage Attached Index

> SAI will follow the same QA/Testing guideline as in CASSANDRA-15536. CASSANDRA-15536 might set some good examples for retrospectively shoring up our quality assurance, but offers no prescriptions for how we approach the testing of new work. I think the project needs to conclude the discussion

Re: [DISCUSS] CEP-7 Storage Attached Index

Last but not least 4) Are collections, static columns, composite partition key composent and UDT indexings (at any depth) on the roadmap of SAI ? I strongly believe that those features are the bare minimum to make SAI an interesting replacement for the native 2nd index as well as SASI. SASI limite

Re: [DISCUSS] A point of view on Testing Cassandra

This totally dropped off my radar; the call out from the SAI thread reminded me. Thanks Benedict. I think you raised some great points here about what a "minimum viable testing" might look like for a new feature: > New features should be required to include randomised integration tests > that exe

Re: [DISCUSS] Revisiting Java 11's experimental status

Where did we land on this? Don't seem to have a clear consensus from thread discussion. On Mon, Jul 20, 2020 at 10:02 PM Deepak Vohra wrote: > The same link was posted earlier also. > For Java 8 and 11 the poll result is very similar. > Java 8 =58.4%Java 11 =22.56% > > > On Monday, July 20,

Re: [DISCUSS] Revisiting Java 11's experimental status

I would propose the following: 1) leave jdk 11 marked as experimental 2) make sure CI runs jdk 8 and jdk 11 for all builds (circle / jenkins) 3) during 4.0 qualification, issues found on jdk 11 should block the release This should get us in good shape to potentially be ready to flip the switch in

Re: Cassandra Kubernetes SIG - status update

Hey John, I’m also in the middle of evaluating this image as I want to test cassandra 4.0-beta1 and am trying to avoid having to handle changes at the configuration level (deprecated/renamed parameters for instance). I also have an issue with the fact the seed_provider class is not parameterize

Re: Cassandra Kubernetes SIG - status update

It sounds like he just included the agent jar which has this class on the CLASSPATH. This feels like an enhancement for the definitions config builder uses to allow for configuration of the seed provider. On Tue, Aug 18, 2020 at 11:00 PM Cyril Scetbon wrote: > Hey John, > > > > I’m also in the m