Re: [DISCUSS] CEP-48: First-Class Materialized View Support

dopts your design that he (and I) consider inferior, or he is prevented from contributing this work. That isn't a functioning community in my mind, so I'll be noping out for a while, as I don't see much value here right now. On 2025/06/06 18:31:08 Blake Eggleston wrote: > Hi B

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

their needs. However, given the complexity of implementing either > approach, we need to select one for the initial CEP deliverables. > > Overall, I’m leaning toward the snapshot-based approach. The > trade-off—additional disk usage during infrequent repairs—seems more > acce

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> but the snapshot repair design is not a viable path forward. It’s the first > iteration of a repair design. We’ve proposed a second iteration, and we’re > open to a third iteration. I shan't be participating further in discussion, but I want to make a point of order. The CEP process has no ve

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

rid will be 10x10, so at the 7th time unit, we can compare 49 Grid cells.TimeCells IntersectingUsability (%)11/100124/100439/1009416/10016525/10025...749/10049..10100/100100JaydeepOn Fri, May 23, 2025 at 2:17 PM Benedict Elliott Smith <bened...@apache.org> wrote:I think a small number of overla

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

original proposal is incomplete without a better repair story and I’m not sure I’d support the cep if it proceeded as is.On Wed, May 21, 2025, at 12:22 PM, Benedict wrote:Depending how long the grid structure takes to build, there is perhaps anyway value in being able to update the snapshot after

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Depending how long the grid structure takes to build, there is perhaps anyway value in being able to update the snapshot after construction, so that when the repair is performed it is as up to date as possible. But, I don’t think this is trivial? I have some ideas how this might be done but they ar

Re: [DISCUSS] How we handle JDK support

needs at any time - we can’t do such breaking changes in a patch release.- Benedict made a great point on performance changes with JDK upgrades - we do not have regular performance testing so probably introducing a new JDK in a patch version will come with a huge warning - test thoroughly and move to

Re: [DISCUSS] How we handle JDK support

Perhaps we should consider back porting support for newer Java LTS releases to older C* versions, and suggesting users upgrade JDK first. This way we can have trunk always on the latest LTS, advancing language feature support more quickly. That is, we would have something like N-2: JDK, JDK-

Re: [DISCUSS] How we handle JDK support

There are performance differences between JVMs. I agree that bug testing of JVM versions for clients is not very important, but isolating JVM characteristic changes from database characteristic changes is important, for me at least.On 20 May 2025, at 17:47, Jon Haddad wrote:If you're upgrading an

Re: [DISCUSS] How we handle JDK support

In-jvm dtests need to execute an upgrade path on a single jvm, but this is close to always possible on the latest jvm. We haven’t hit any issues that I know of in this respect during any version change, so I don’t think this is a real concern.Some users do care about overlapping JVM compatibility.

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> Like something doesn't add up here because if it always includes the base > table's primary key columns that means they could be storage attached by just > forbidding additional columns and there doesn't seem to be much utility in > including additional columns in the primary key? You can re-

Re: [VOTE] CEP-46: Finish Transient Replication/Witnesses

+1On 12 May 2025, at 15:45, Josh McKenzie wrote:+1On Mon, May 12, 2025, at 10:41 AM, Jon Haddad wrote:+1On Mon, May 12, 2025 at 7:28 AM Ariel Weisberg wrote:Hi dev@, I would like to start the voting for CEP-46: Finish Transient Replication/Witnesses Proposal: https://cwiki.a

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

10:14 AM, Vivekanand Koya wrote:Sounds great. I would like to refactor the codebase (Trunk 5+) to eliminate unsafe explicit casting with instanceOf. Thanks,VivekanandOn Fri, May 9, 2025, 5:19 AM Benedict Elliott Smith <bened...@apache.org> wrote:Yep, that approach seems more than sufficient

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

we landed) > > Assuming we just lazily evaluate and deal with new features as people > actually care about them and seeing them add value, a simple "[DISCUSS] I'm > thinking about using new language feature X; any objection?" lazy consensus > that we then dum

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

I think it doesn’t cost us much to briefly discuss new language features before using them. Lambdas, Streams and var all have problems - and even with the guidance we publish some are still misused. The flow scoping improvement to instanceof seems obviously good though. > On 9 May 2025, at 12:3

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I should add that I’m in favour of this proposal in principle, and support the proposal to utilise Paxos.On 9 May 2025, at 08:21, Benedict Elliott Smith wrote:I’d also like to explore a bit further the isolation guarantees we’re promising with "Strict Consistency Mode” - and the protocol de

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I’d also like to explore a bit further the isolation guarantees we’re promising with "Strict Consistency Mode” - and the protocol details. By strict, do we mean linearizable? Either way, we should state the guarantees explicitly so we can evaluate whether the protocol can meet them. Also, if the

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

; and I also think the current implementation adds a lot of complexity to the >>> codebase for being stuck in experimental mode. It will be great to have a >>> more robust version built on a better approach. >>> >>> On Sun, May 4, 2025 at 00:27 Benedict >> <mai

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 This is an obviously good feature for operators that are storage-bound in multi-DC deployments but want to retain their latency characteristics during node maintenance. Log replicas are the right approach. > On 3 May 2025, at 23:42, sc...@paradoxica.net wrote: > > Hey everybody, bumping th

Re: [DISCUSS] Requirement to document features before releasing them

I am opposed to this. There’s too much imprecision in the “rule” while simultaneously being much too rigid, and it will be improperly enforced (we already have lots of rule breaking around modifying public APIs, that should have discuss threads and do not, for instance). This kind of arbitrary rule

Re: [DISCUSS] auto-installing golang in `ant gen-doc` (CASSANDRA-19915)

We should never download and install software via adhoc scripts without user consent. Was this ever discussed on this mailing list? If not, it’s a clear breach of policy (introducing a new dependency) and a severe one in my opinion, as it seems to introduce a new supply chain attack vector for a

Re: Python and Go callouts during ant compile/build task

We should separate out any grade discussion. I’m happy to migrate accord to ant if that’s the project preference, but there’s continual discussion to begin modularising Cassandra (at least a little), and a proposal to use grade for the modules - which might be a happy medium for everyone’s competin

Re: [DISCUSS] How we version our releases

I’d much rather we agree to try NOT to deprecate or break things full stop. But once we decide there’s good reason to, I don’t think arbitrary lifetimes for a feature are really all that helpful are they?On 18 Apr 2025, at 20:03, Josh McKenzie wrote:I personally feel that patch level fixes should

Re: [VOTE] Simplifying our release versioning process

+1We have already agreed some time ago that any incompatible API change requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki.I agree with Scott: our norm should be NOT breaking things. There should be strong justification in terms of either development friction or an unsafe or poo

Re: CEP-15 Update

slack if you have any trouble. > On 16 Mar 2025, at 10:44, Benedict Elliott Smith wrote: > > Hi everyone, > > To update you: the last patches we considered blockers have landed in the > cep-15-accord branch. Caleb has now started rebasing the branch onto trunk. I > expec

Re: Constraint's "not null" alignment with transactions and their simplification

ANSI SQL where possible so as not to paint ourselves into a corner nor alienate our users, but I do believe there's value in having a consistent UX while acknowledging and accommodating that things aren't necessarily consistent in the SQL space.Are you against offering a superset of that

Re: Constraint's "not null" alignment with transactions and their simplification

If we have a goal of eventually providing ANSI SQL support one day, we should at least stick to the ANSI SQL standard where applicable for features in the meantime. AFAICT the reason everyone else does this the same is it is part of the standard. So, I am more than happy to stick to the CHECK quali

Re: Constraint's "not null" alignment with transactions and their simplification

such a limitation on users and force them to define every column present in a constraint, or do we break the SQL spec?  If we choose to break the spec, then why allow column names in the search expressions?  Only “this” column is safeOn Apr 14, 2025, at 1:24 PM, Benedict wrote:If we have a g

Re: Constraint's "not null" alignment with transactions and their simplification

ld be to change the constraint name to IS_JSON. CHECK IS_JSON would read as you intend without the need to jump to REQUIRE. I think that’s true for the rest of provided constraints as well.BernardoOn Apr 11, 2025, at 6:02 AM, Benedict <bened...@apache.org> wrote:We have taken a different appro

Re: Constraint's "not null" alignment with transactions and their simplification

without the need to jump to REQUIRE. I think that’s true for the rest of provided constraints as well.BernardoOn Apr 11, 2025, at 6:02 AM, Benedict wrote:We have taken a different approach though, as we do not actually take a predicate on the RHS and do not supply the column name. In our examples we

Re: Constraint's "not null" alignment with transactions and their simplification

-constraints.html#DDL-CONSTRAINTS-CHECK-CONSTRAINTShttps://dev.mysql.com/doc/refman/8.4/en/create-table-check-constraints.htmlOn Fri, Apr 11, 2025 at 10:43 AM Benedict <bened...@apache.org> wrote:I would prefer require/expect/is over checkOn 11 Apr 2025, at 08:05, Štefan Miklošovič <smikloso...@a

Re: Constraint's "not null" alignment with transactions and their simplification

I would prefer require/expect/is over checkOn 11 Apr 2025, at 08:05, Štefan Miklošovič wrote:Yes, you will have it like that :) Thank you for this idea. Great example of cooperation over diverse domains.On Fri, Apr 11, 2025 at 12:29 AM David Capwell wrote:I am biased but I do

Re: [DISCUSS] How we version our releases

I proposed dropping Minor versions a few years ago so I’m cool with this, but regarding policies I do think we’d be better off just creating a version compatibility matrix and quit agonising over it. With N policies across N releases I’m not sure they’re providing much certainty to users. We really

Re: Inconsistent null handling between WHERE and IF clauses

Modifying the behaviour for IF clauses is a major breaking change that could have disastrous effects for customers, that would be very hard to audit applications for on upgrade, so I think that option is a non-starter. I would support an effort to introduce a new session mode where we make ours

Re: Inconsistent null handling between WHERE and IF clauses

ull as we might not know it’s > null till we do and LET clause, so null in operation becomes false is my > stance > > Sent from my iPhone > >> On Mar 24, 2025, at 10:46 PM, Benedict wrote: >> >> Modifying the behaviour for IF clauses is a major breaking ch

Re: [DISCUSS] Plugins and dependencies

7;t change.  Jon[1] https://docs.gradle.org/current/userguide/multi_project_builds.html[2] https://maven.apache.org/guides/mini/guide-multiple-modules.htmlOn Mon, Mar 17, 2025 at 7:15 AM Benedict <bened...@apache.org> wrote:I can only speak for myself, but the overhead of managing the accord su

Re: [DISCUSS] Plugins and dependencies

changes across multiple repos.On Sun, Mar 16, 2025 at 4:26 AM Benedict Elliott Smith <bened...@apache.org> wrote:I want to break out at least one or two shared library projects. Both accord and in-jvm-dtest-api should share code with the Cassandra main project, particularly executors/f

Re: [DISCUSS] Plugins and dependencies

ut IAM for login, it sounds like a similar >>>> problem. >>> That was me. :-) Cassandra's auth already has fairly well defined >>> interfaces and a plug-in mechanism, so it's easy to vend alternative auth >>> solutions without polluting the

Re: CEP-15 Update

intenance is causing overhead that could be spent on > finalisation. +1 on merging, particularly given the feature flag work. > > Once more unto the breach 💪 > > On Fri, 7 Mar 2025 at 6:56 PM, Benedict <mailto:bened...@apache.org>> wrote: >> There are essential

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

it is definitely not possible to merge / convert.https://lists.apache.org/thread/8xscy9q0s8rqhsfovj03656zdh29qlnpOn Wed, Mar 12, 2025 at 12:55 PM Benedict Elliott Smith <bened...@apache.org> wrote:Hi Stefan,My reading of this mailing list thread is that they think clearspring is junk (probabl

Re: Dropwizard/Codahale metrics deprecation in Cassandra server

we can anticipate broad user confusion/interest. > > In particular if latency stats are reported higher post-upgrade, we should expect users to interpret this as a performance regression, dedicating significant resources to investigating the change, and expending credibility with stakeholders

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

format and the rest on new format - still merge all Clearspring logsin case all SSTables are on new format - merge DatasketchesI haven't looked at it this way. I'll play with it.On Wed, Mar 12, 2025 at 12:55 PM Benedict Elliott Smith <bened...@apache.org> wrote:Hi Stefan,My reading

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

the legacy sstables to the new sketches. This would be fine in my book, and probably much simpler. > On 12 Mar 2025, at 11:37, Štefan Miklošovič wrote: > > Benedict, > > I have reached Datasketches community (1) and asked what they think about > Clearspring and if it

Re: CEP-15 Update

blake.com>> wrote: >> +1 to merging it >> >> On Wed, Mar 5, 2025, at 12:22 PM, Patrick McFadin wrote: >>> You have my +1 >>> >>> On Wed, Mar 5, 2025 at 12:16 PM Benedict >> <mailto:bened...@apache.org>> wrote: >>> >

Re: CEP-15 Update

My understanding then is that we are free to merge once we are ready? We will be directing our resources on this basis, so please pipe up promptly if you disagree. We will update the list once we have our final patches merged (which should be a good time to kick the tyres for those inclined), an

Re: CEP-15 Update

folks have concerns, it's easy to fire up a cluster (I do it constantly) and try it out.I think if we were to do this, out of consideration we should time box the amount of time for an evaluation and unless someone raises an objection, consider lazy consensus achieved.JonOn Thu, Mar 6, 2025 at 12

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

dtest does this already.  Someone just started asking about IAM for login, it sounds like a similar problem. On Thu, Mar 6, 2025 at 12:53 AM Benedict <bened...@apache.org> wrote:I think another way of saying what Stefan may be getting at is what does a library give us that an appropriately conf

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

I think another way of saying what Stefan may be getting at is: what does a library give us that an appropriately configured mount dir doesn’t?We don’t want to treat S3 the same as local disk, but this can be achieved easily with config. Is there some other benefit of direct integration? Well defin

Re: CEP-15 Update

caveats apply when someone is not using Accord.  Assuming they only apply when the feature flag is enabled, I see no reason not to get this merged into trunk once everyone involved is happy with the state of it.-Jeremiah On Mar 5, 2025 at 12:15:23 PM, Benedict Elliott Smith <bened...@apache.

Re: Dropwizard/Codahale metrics deprecation in Cassandra server

memetables + offheap objects modeI disabled compactiona recent nightly build is used for async-profilermy hardware is quite old: on-premise VM, Linux 4.18.0-240.el8.x86_64, OpenJdk-11.0.26+4, Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz, 16 coreslink to CPU profile ("codahale" code: 8.65%)-

Re: CEP-15 Update

n 5 Mar 2025, at 17:22, Patrick McFadin wrote: > > What is the timing for starting the merge process? I'm asking because > I have (yet another) presentation and this would be a cool update. > > On Wed, Mar 5, 2025 at 1:22 AM Benedict Elliott Smith > wrote: >> >&

Re: Dropwizard/Codahale metrics deprecation in Cassandra server

ard-for-apache-cassandra-business-platform-team/ > [2] https://opentelemetry.io/docs/collector/ > > On Tue, Mar 4, 2025 at 12:40 PM Dmitry Konstantinov <mailto:netud...@gmail.com>> wrote: >> Hi all, >> >> After a long conversation with Benedict and Maxim in CAS

Re: CEP-15 Update

to the new Cassandra epoch! >> >> On Tue, 4 Mar 2025 at 20:45, Blake Eggleston > <mailto:bl...@ultrablake.com>> wrote: >>> Thanks Benedict! >>> >>> I’m really excited to see accord reach this milestone, even with these >>> caveats

CEP-15 Update

Hi everyone, It’s been exactly 3.5 years since the first commit to cassandra-accord. Yes, really, it’s been that long. We will be starting to validate the feature against real workloads in the near future, so we can’t sensibly push off merging much longer. The following is a brief run-down of

Welcome Jeremiah Jordan to the PMC

The PMC is happy to announce that Jeremiah Jordan has joined its membership. Jeremiah has been a member of this community for almost 15 years. I hope you will join me in welcoming him to the committee.

Re: [Discuss] Decoupling java driver dependency from server code; migrate tools and tests to 4.x driver

One thing to consider in this discussion is integration with dtests, and in particular the simulator. It would help to improve coverage if we had a “client” that could operate without going over the network (or, going over a simulated network), so that it can be controlled by the simulator. The

Re: Meaningless emptiness and filtering

Perhaps we should reify this in the type system? Introduce a MAYBE EMPTY modifier for column types, or simply name them eg [int] vs int?I think the problem is today it’s all implicit and - as David says - inconsistent. It would be nice to move away from this as the default for a variety of reasons,

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

ffect preexisting data.”Long story short, constraints are only checked at write time. If a constraint is added to a table with preexisting offending data, that data stays untouched.I hope this helps,BernardoOn Feb 10, 2025, at 7:00 AM, Benedict wrote:This is counterintuitive to me. The constraint shou

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

This is counterintuitive to me. The constraint should be applied to the table, not to the update. NOT NULL should imply a value is always specified. How are you handling this for tables that already exist? Can we alter table to add constraints, and if so what are the semantics? > On 10 Feb 2025

Re: [DISCUSS] Default Selection of 2i

Oof, if nothing else it sounds like a bug that we prefer an unbuilt index over a built one when there’s a choice.It also sounds like a bug for SAI to self report as the best index without any consideration, but perhaps that is harder to address.On 6 Feb 2025, at 21:15, C. Scott Andreas wrote:Pref

Re: Capabilities

t here as well.  We could remove the custom code around auth cache in the process.JonOn Mon, Jan 6, 2025 at 12:48 PM Benedict Elliott Smith <bened...@apache.org> wrote:The more we talk about this, the more my position crystallises against this approach. The feature we’re discussing here should

Re: Patch Available vs Needs Committer

Patch available means the PR is ready for review.Needs committer means we think it’s ready to merge but we need at least one more committer +1 (and maybe one to actually merge).There’s a requirement that at least one contributor reviews a patch. There’s a separate a requirement that two committers

Re: [DISCUSS] 5.1 should be 6.0

polity actually wants, collectively. That’s fine, let’s be at peace with it. > On 29 Jan 2025, at 16:00, Josh McKenzie wrote: > >  > I've let this topic sit in my head overnight and kind of chewed on it. While > I agree w/the "we're doing what matches our unspoken

Re: [DISCUSS] 5.1 should be 6.0

I agree there’s probably some value captured in having ccm tests, but I suspect not in most of the python tests we have, which are all but unmaintained at this point. When I looked at them last I was surprised at how rubbish many of them were. I think we need a plan to maintain them properly, a

Re: [DISCUSS] 5.1 should be 6.0

But to your point, if trying to > formalize it doesn't yield results, that's just objectively worse since it's > adding more churn on top of a churn-heavy process. /sigh > > On Tue, Jan 28, 2025, at 11:01 AM, Benedict wrote: >> >> We revisit this basically

Re: [DISCUSS] 5.1 should be 6.0

We revisit this basically every year and so I’m sort of inclined to keep the status quo which really amounts to basically doing whatever we end up deciding arbitrarily before we actually cut a release. Before discussing at length a new policy we’ll only immediately break, if the motivation is

Re: [DISCUSS] 5.1 should be 6.0

Yeah, my position is this isn’t a problem. The full range of upgrade tests only need to be run at most on release, and we’re not talking about supporting loads of versions. I think it’s fine to (as before) expect people upgrade from and to the highest patch version of any minor release, so the m

Re: [DISCUSS] Bracing style on trunk

style guide. Jordan On Mon, Jan 20, 2025 at 06:50 Benedict <bened...@apache.org> wrote:I think if we want to we can refine the rules a little while we’re all here discussing it anyway.We could for instance just stipulate the specific scenarios where it must happen, ie: multi-line if or loop

Re: [DISCUSS] Bracing style on trunk

va <e.dimitr...@gmail.com> wrote:> > >>>>> > >>>> I also do not see huge benefit in switching the style, honestly. And I see risks more than benefits.> > >>>>> > >>>> I also share Blake’s opinion that thi

Re: [DISCUSS] CEP-45: Mutation Tracking

e not thinking about and it wouldn't be a bad idea to write most recent mutation id to a table every few seconds asynchronously so we don't create a giant mess if we restart during them.On Jan 18, 2025, at 2:18 AM, Benedict wrote:Does this approach potentially fail to guarantee m

Re: [DISCUSS] Bracing style on trunk

This is a mad idea that I can’t believe anyone is seriously entertaining. -1.On 18 Jan 2025, at 13:17, Josh McKenzie wrote:Trying to break out discussions here to keep things moving - see thread "Checkstyle as style contract for Cassandra"One topic that came up on the thread was whether we were c

Re: [DISCUSS] CEP-45: Mutation Tracking

Does this approach potentially fail to guarantee multi table atomicity? If we’re reconciling mutation ids separately per table, an atomic batch write might get reconciled for one table but not another? I know that atomic batch updates on a single partition key to multiple tables is an important pro

Re: Checkstyle as style contract for Cassandra

orms to a style guide with artisanal spacing.  I'm not sure who benefits from the manual work.Code is meant to be read, consistency is good, and makes it easier.Jon On Fri, Jan 17, 2025 at 10:12 AM Benedict <bened...@apache.org> wrote:I’m amazed at the number of people who take no pri

Re: Checkstyle as style contract for Cassandra

be a post-accord consideration so at least mainline rebase pain would be minimized, and if we kept it to trunk-only that'd probably be fine. >>> >>> Should we put together a review guideline for the project? Worth considering for us as a project; Benedict indicated receptivity

Re: Checkstyle as style contract for Cassandra

inclination.On Thu, Jan 16, 2025, at 9:17 AM, Benedict wrote:I can imagine that it might cause some frustrating review interactions people would like to avoid, but for solving that I’d prefer we take a more social approach. Review shouldn’t spend much time on minor style points, and these should normally

Re: Checkstyle as style contract for Cassandra

r an org I was managing at the time: https://google.github.io/eng-practices/review/reviewer/Been years; might be worth it to have a skim through that and see if it could serve as a reasonable starting point for us if someone has the inclination.On Thu, Jan 16, 2025, at 9:17 AM, Benedict wrote:I can

Re: Checkstyle as style contract for Cassandra

sues/12226).I think if we were to add a new rule around brackets and newlines, we would ideally try to make it match the Code style definition as its declared, and hopefully it would not be too require touching a lot of files (which maybe the case unfortunately).Thanks,AndyOn Wed, Jan 15, 2025 at 6:10 P

Re: Checkstyle as style contract for Cassandra

Even something as simple as the curly brace rule has sensible exceptions. I’m pretty hard -1 on letting a linter make all our editing decisions. Formatting is a contextual choice about how to best represent information to the reader, and we should not abdicate responsibility. The style guide is

Re: Capabilities

subsystem *almost* works as is for the new >>>>> feature, but doesn't *quite* work as is, so changes are made to it, and >>>>> reviewed, by someone not familiar enough with the subsystem design and >>>>> implementation. One of such changes ev

Re: [DISCUSS] CASSANDRA-20163 DELETE partition IF static column condition is currently blocked

c condition >> DELETE >> FROM tbl >> WHERE pk = ? — pk is the only partition key, but there are clustering keys >> IF s0 = ? — s0 is static >> >> >> I took a stab at fixing this in >> https://issues.apache.org/jira/browse/CASSANDRA-20163 and speaking wit

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

ven't even started to merge the logs).If this is still not something which would sell Datasketches as a viable alternative then I guess we need to stick to these numbers and cache it all with Clearspring, occupying way more memory.On Thu, Jan 2, 2025 at 10:15 PM Benedict <bened...@apache

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

//github.com/addthis/stream-lib/issuesOn Thu, Jan 2, 2025 at 9:26 PM Benedict <bened...@apache.org> wrote:Your message seemed to be all about the caching proposal, which I have proposed we separate, hence my confusion.To restate my answer to your question, I think that unless the new library act

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

threw dependencies in willynilly. But it has the benefit of having been used for a very long time without incident.On 2 Jan 2025, at 20:12, Štefan Miklošovič wrote:Hi Benedict, you wrote:I am strongly opposed to updating libraries simply for the sake of it. Something like HLL does not need much

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

I’m confused Stefan, in what way do you protest? How is your proposal to cache these collections tied to the topic you started here? This should be a separate proposal, discussed on its own merits independently, should it not?I am not opposed to it happening, only to conflating the two concerns.On

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

I am strongly opposed to updating libraries simply for the sake of it. Something like HLL does not need much ongoing maintenance if it works. We’re simply asking for extra work and bugs by switching, and some risk without understanding the quality control for the new library project’s releases.That

Re: Capabilities

ngly consistent. Exposing features to clients based on whether the entire cluster supports them seems like the kind of thing that could cause pain if we're in a split-brain, cluster-is-settling-on-agreement kind of paradigm.On Fri, Dec 20, 2024, at 3:17 PM, Benedict wrote:Mostly conceptual; t

Re: Capabilities

, Dec 20, 2024 at 11:06 AM Benedict <bened...@apache.org> wrote:If TCM breaks we all have a really bad time, much worse than if any one of these features individually has problems. If you break TCM in the right way the cluster could become inoperable, or operations like topology changes may be pre

Re: Capabilities

what really matters is that cluster and schema membership changes do not happen while a miscellaneous operation is taking place.Would this make sense as an initial way to integrate TCM with capabilities framework ?On Fri, Dec 20, 2024 at 4:53 AM Benedict <bened...@apache.org> wrote:If you per

Re: Capabilities

of putting all parts of the puzzle together so please be so nice to prove me wrong. RegardsOn Fri, Dec 20, 2024 at 10:53 AM Benedict <bened...@apache.org> wrote:If you perform a read from a distributed table on startup you will find the latest information. What catchup are you thinking of? I d

Re: Capabilities

air it etc ... It might be the source of the discrepancies / disagreements etc. TCM is just "maintenance-free" and _just works_. I think I was also investigating distributed tables but was just pulled towards TCM naturally because of its goodies.On Fri, Dec 20, 2024 at 10:08 AM Benedict

Re: Capabilities

TCM is a perfectly valid basis for this, but TCM is only really *necessary* to solve meta config problems where we can’t rely on the rest of the database working. Particularly placement issues, which is why schema and membership need to live there.It should be possible to use distributed system tab

Re: Supporting 2.2 -> 5.0 upgrades

cassandra-all and can limit the dependencies)… if we did that we could try to solve this as an out of process migration… have the 2.2 reader then write using 6.0 writer (ignoring compact storage… )… > >> On Dec 11, 2024, at 4:59 AM, Benedict <bened...@apache.orgbened...@apache.org>&

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

the feature within the next year or so we should deprecate it entirely.+1 - this is probably topic for another thread but isn’t MVs fundamentally solved with Accord? In my ignorance this is “just” a matter of adding an Accord backend to MV syntax to fix it reliably.On Thu, 12 Dec 2024 at 09:58 Bened

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

imum necessary policy to proceed todayDefinitely agree; MV's being in limbo for years strains the "3-step classification" structure for me. If we want to avoid having a solution for the MV-shaped case on the grounds we won't allow ourselves to reach this state again in the future

Re: [DISCUSS] 5.1 should be 6.0

It might not be too bad if done selectively? I agree that would be infeasible for each patch. How many SCM modes do we have? I worry more about developer burden. It sounds like we have a balancing act with SCM complexity versus upgrade complexity. I think at the very least we should require th

Re: Supporting 2.2 -> 5.0 upgrades

ht? I guess 2.2 -> 3.0 already works, we would just try to support > 2.2 -> 3.11 straight away. I need to check where we are at in that area. > > ____ > From: Benedict > Sent: Wednesday, December 11, 2024 13:09 > To: dev@cassandra.a

Re: Supporting 2.2 -> 5.0 upgrades

2.2 is particularly hard because of the major storage format changes that took place. I think if we want to retain (restore) upgrade support from 3.x I would support that, but 2.x is probably too burdensome and likely to have too many hard edges. I think if users only had to upgrade 2.2->3.x th

Re: [DISCUSS] 5.1 should be 6.0

n. :pWhat you call marketing, I call end-user communication. I'll leavethis open question, but what do we want to communicate to the userbase, and how should they approach this new feature set?PatrickOn Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith<bened...@apache.org> wrote:>>

Re: [DISCUSS] 5.1 should be 6.0

estion, but what do we want to communicate to the userbase, and how should they approach this new feature set?PatrickOn Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith<bened...@apache.org> wrote:>> This is another topic we basically revisit afresh every time :)>> I think it

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

atures experience a state change, finding more > avenues to get the word out will be important. > > On Tue, Dec 10, 2024 at 10:04 AM Benedict Elliott Smith > wrote: >> >> As an aside, it would be nice to admit we basically revisit everything each >> time it become

  1   2   3   4   5   6   7   8   >