Re: [VOTE] CEP-54: ZSTD with Dictionary SSTable Compression

+1 > On Sep 10, 2025, at 11:19 AM, Jindal, Himanshu wrote: > > +1 > > From: Jon Haddad > Date: Wednesday, September 10, 2025 at 11:00 AM > To: dev@cassandra.apache.org > Subject: RE: [EXTERNAL] [VOTE] CEP-54: ZSTD with Dictionary SSTable > Compression > > CAUTION: This email originated from

Re: [DISCUSS] CEP-54: ZSTD Compression with Dictionary Support

Thanks for bringing this out! My first question when quickly looking at this is can we make the CompressionInfo change agnostic to the algorithm or have the format change based off the algorithm? Lz4 has similar (though not as easy to use as zstd) feature and new algorithms might come out whic

Re: [VOTE] Release Apache Cassandra 4.1.10

+1 > On Aug 29, 2025, at 7:06 AM, Brandon Williams wrote: > > +1 > > Kind Regards, > Brandon > > On Thu, Aug 28, 2025 at 8:26 AM Štefan Miklošovič > wrote: >> >> Proposing the test build of Cassandra 4.1.10 for release. >> >> sha1: d48bfcce442489de45797ecdf3bde7574ade42d5 >> Git: https://gi

Re: [ANNOUNCE] Pre-commit CI @ pre-ci.cassandra.apache.org , an AWS donation

This >> has also included getting our CI pipeline generating aggregated test result >> artefact files that can easily be attached to jira tickets, and archived >> permanently. These objectives you can see listed in CASSANDRA-18137³. >> >> For all this special thanks go

Re: [DISCUSS] Online upgrade procedure to 5.x and storage_compatibility_mode

Looking over the code the single usage that differs between UPGRADING and NONE is org.apache.cassandra.db.rows.Cell#getVersionedMaxDeletiontionTime public static long getVersionedMaxDeletiontionTime() { if (DatabaseDescriptor.getStorageCompatibilityMode().disabled()) // The whole cl

Re: Welcome Lukasz Antoniak as Cassandra committer on the Drivers subproject!

Congrats! > On Aug 21, 2025, at 3:26 PM, Jaydeep Chovatia > wrote: > > Congratulations! > > On Thu, Aug 21, 2025 at 3:25 PM Tolbert, Andy > wrote: >> Congrats Lukasz!! >> >> On Thu, Aug 21, 2025 at 10:17 PM Yifan Cai > > wrote: >>> Co

Re: Welcome Branimir Lambov as Cassandra PMC member

Congrats! > On Aug 21, 2025, at 3:26 PM, Tolbert, Andy wrote: > > Congratulations Branimir! > > On Thu, Aug 21, 2025 at 10:15 PM Josh McKenzie > wrote: >> Congratulations Branimir! It's been great to collaborate with you over the >> years. Looking forward to more.

Re: [DISCUSS] Java SPI way of loading custom implementations

I have 0 issues with ServiceLoader, but I think the bigger question is “what is a public api”. In #1 I see the first comment is > The `CustomConstraintsProvider` class will create custom constraints. This implies to mean that this is a new public API that must be maintained, and the current p

Re: Accepting AI generated contributions

e (there may be cases, but we should treat those in isolation as the same concern happens with human code). OpenAI called out that you can’t use their output to build something to compete with them, which is what was flagged as being against the “Open Source Definition”. > > On Fri, Aug 1,

Re: Accepting AI generated contributions

s on this topic or is there still further discussion to be had?On Thu, Jul 24, 2025, at 8:26 AM, David Capwell wrote:Given the above, code generated in whole or in part using AI can be contributed if the contributor ensures that: The terms and conditions of the generative AI tool do not place any r

Re: Accepting AI generated contributions

and code reviews. PatrickOn Wed, Jul 23, 2025 at 11:31 AM David Capwell <dcapw...@apple.com> wrote:David is disclosing it in the maillist and the GH page. Should the disclosure be persisted in the commit? Someone asked me to update the ML, but I don’t believe or agree with us assuming we sh

Re: Accepting AI generated contributions

t;> I could have written this my self but I had to focus on code reviews and >>> also needed this patch out, so asked Claude to write it for me so I could >>> focus on reviews. I have reviewed it myself and it’s basically the same >>> code I would have writ

Re: Accepting AI generated contributions

, larger stuff doesn’t normally pass my peer review). > On Jun 25, 2025, at 2:37 PM, David Capwell wrote: > > +1 to what Josh said > Sent from my iPhone > >> On Jun 25, 2025, at 1:18 PM, Josh McKenzie wrote: >> >>  >> Did some more digging. Apparently

Re: Accepting AI generated contributions

sclose if they used AI, what models, > and whether they used the code or text the model wrote verbatim or used it as > a scaffolding and then heavily modified everything I think we'll be in a > pretty good spot. > >> On Wed, Jun 25, 2025, at 12:47 PM, David Capwell wrote: >

Re: Accepting AI generated contributions

> 2. Models that do not do output filtering to restrict the reproduction of > training data unless the tool can ensure the output is license compatible? > > 2 would basically prohibit locally run models. I am not for this for the reasons listed above. There isn’t a difference between this and

Re: Accepting AI generated contributions

he stance that disclosure (which is the ASF policy) is >> best for the time being; nothing in this thread has motivated me to change >> the current policy. > Yep. Option 2 - guidance and disclosure makes the most sense to me after > reading this thread. > > On Tue, Jun 24, 2025,

Re: Accepting AI generated contributions

gt;>> existing copyright holder -- it is very much ON YOU as a committer/PMC to >>> prevent that from happening. >>> >>> >>> We aren't supposed to knowingly allow people to use AI tools that are >>> known to generate infringing contributi

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

to roll their own > solution. > > > On Fri, Jun 20, 2025 at 10:24 AM David Capwell <mailto:dcapw...@apple.com>> wrote: >>> However, for folks like me that know the command line options and regularly >>> do things that you might not have planned out, I'd ap

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

> However, for folks like me that know the command line options and regularly > do things that you might not have planned out, I'd appreciate an escape hatch > where I can pass my raw commands For more “advanced” users, normal profile.sh would still be able to profile, just requires more steps.

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

I am in favor of the project adopting as a library. My automation is very outdated, so what I am saying maybe a legacy thing… so w/e is the “new” way is what we should promote…. I rely a lot on the collapsed format and wish to migrate to the JFR format so I can collect CPU / Memory at the same

Re: [VOTE] Clarifying our JDK Support Policy

+1 > On Jun 17, 2025, at 3:44 AM, Štefan Miklošovič wrote: > > +1 > > On Fri, Jun 13, 2025 at 1:58 PM Josh McKenzie > wrote: >> [DISCUSS] thread: >> https://lists.apache.org/thread/vr7j2ob92k6fbcwvlfo60l3scylzdbft >> >> Text to vote on: >> ---

Re: Accepting AI generated contributions

on how you interpret > them and we are not very well equipped to interpret them. > > It would have been more straightforward for them to simply say no, but they > didn't opt to do that as if there is some way for PMCs to acceptably take AI > generated contributions. >

Re: Accepting AI generated contributions

> fine tuning encourage not reproducing things verbatim > I think not producing copyrighted output from your training data is a > technically feasible achievement for these vendors so I have a moderate level > of trust they will succeed at it if they say they do it. Some team members and I discu

Re: [DISCUSS] GnuParser / Posix command like argument parser in tools

> What is the official policy we have around arguments parsing? From a style point of view I don’t think its something the project has taken a stance on, its something you define as the author to the CLI you are working on. > What kind of style should we default to for tools? Posix or Gnu? From

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats! > On May 19, 2025, at 4:13 AM, Dmitry Konstantinov wrote: > > Congratulations Bret! > > On Mon, 19 May 2025 at 00:51, Bret McGuire > wrote: >> Thank you everyone for the kind words! >> >>- Bret - >> >> On Sat, May 17, 2025 at 11:44 PM Patrick Mc

Re: CASSANDRA-20490 Question about broken forced ephemeral snapshots during repair

inisticId is basically unique? I see it is created from parent id, session id, keyspace, table and ranges. I do not think there would ever be two cases of snapshots like that with exact same values.WDYT?RegardsOn Mon, May 12, 2025 at 6:55 PM David Capwell <dcapw...@apple.com> wrote:> &qu

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

+1 > On May 12, 2025, at 9:26 AM, Štefan Miklošovič wrote: > > +1, great stuff, looking forward to bring it out of experimental > > On Mon, May 12, 2025 at 4:27 PM Ariel Weisberg > wrote: >> Hi dev@, >> >> I would like to start the voting for CEP-46: Finish Transient

Re: Welcome Abe Ratnofsky as Cassandra committer!

Congrats! > On May 12, 2025, at 9:45 AM, Alex Petrov wrote: > > Hello folks of the dev list, > > The Apache Cassandra PMC is very glad to announce that Abe Ratnofsky has > accepted our invitation to become a committer! > > Abe has been actively contributing to Cassandra itself, made outstandi

Re: CASSANDRA-20490 Question about broken forced ephemeral snapshots during repair

> "force" can be true / false. When true, then it will not check if a snapshot > exists My mental node for “force” was only to deal with down nodes, and nothing to do with snapshots… so this feels like a weird behavior @Option(title = "force", name = {"-force", "--force"}, description = "Use

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

> The MV repair tool in Cassandra is intended to address inconsistencies that > may occur in materialized views due to various factors. This component is the > most complex and demanding part of the development effort, representing > roughly 70% of the overall work. > but I am very concerned ab

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

> I think the primary argument *against* Accord is that the syntax isn't > expressive enough to be able to address multiple conditions in MVs. For each > field that's updated, you'll need to know if you want to add that update into > the transaction, and you'd need to check if it was modified.

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

+1 > On May 6, 2025, at 10:53 AM, Dmitry Konstantinov wrote: > > +1 (nb) > > On Tue, 6 May 2025 at 17:32, Aleksey Yeshchenko > wrote: >> +1 >> >>> On 5 May 2025, at 23:24, Blake Eggleston >> > wrote: >>> >>> As mutation tracking relates

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

I wonder at what level can we enforce this. What I mean, in modeling testing I have found some odd behaviors that people were not aware of (BATCH cell resolution, NULL handling (emptiness…..), etc.)… so if documentation is dense this can help force people to think through edge cases or how 2 fe

Re: [VOTE][IP CLEARANCE] easy-cass-stress

+1, I am open to different names, I am cool with easy-cass-stress > On Apr 30, 2025, at 9:27 AM, Francisco Guerrero wrote: > > +1 (nb) > > On 2025/04/30 15:15:57 Jordan West wrote: >> (general@incubator cc'd) >> >> Please vote on the acceptance of the easy-cass-stress (to be renamed >> cassand

Re: Welcome David Capwell as Cassandra PMC Member!

;>> >>>> On Mon, Apr 28, 2025, at 3:09 PM, Jon Haddad wrote: >>>>> Hey everyone! >>>>> >>>>> The Project Management Committee (PMC) for Apache Cassandra is delighted >>>>> to announce that David Capwell has joined t

Re: Welcome David Capwell as Cassandra PMC Member!

gt; >> >>> >> From: Abe Ratnofsky mailto:a...@aber.io>> >>> >> Sent: Monday, April 28, 2025 12:11:52 PM >>> >> To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org> >>> >> mailto:dev@cassandra.apache.org>> >>> >> Subject: Re: Welcome David Capwell as Cassandra PMC Member! >>> >> >>> >> Congrats David! >

Re: [VOTE] Simplifying our release versioning process

> Also, I thought we had separate discussion about them - that we want to keep > up possibly with the last two LTS versions. This is what I remember as well. 6.0 would support 17/21 as thats the latest, if 7.0 is out before 25, then 7.0 would be 17/21, else it would be 21/25 > On Apr 23, 2025,

Re: [DISCUSS] How we version our releases

a software like > this, even that case doesn't really give me much heartburn. We shouldn't do > that of course, but even that extreme doesn't seem like it'd cause too much > pain. > > On Thu, Apr 17, 2025, at 2:53 PM, David Capwell wrote: >>> Does it me

Re: CEP-15 Update

; >>>>>>>>> >> >>>>>>>>> >> > On Tue, Mar 4, 2025 at 9:57 AM Dmitry Konstantinov >>>>>>>>> >> > mailto:netud...@gmail.com>> wrote: >>>>>>>>> >> >>&g

Re: [DISCUSS] How we version our releases

> Does it mean that one has to flag a feature as deprecated in the unreleased > version N, wait until when N is released (deprecating for one major cycle), > and then finally make the breaking change in N + 1? My understanding is things are not different than before, we just don’t do minors; wh

Re: [VOTE] Simplifying our release versioning process

+1 > On Apr 17, 2025, at 9:22 AM, Jon Haddad wrote: > > +1 > > On Thu, Apr 17, 2025 at 9:15 AM Josh McKenzie > wrote: >> +1 >> >> On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote: >>> [DISCUSS] thread: >>> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz

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

One argument I have against using columns in the constraint is that we currently are not able to actually handle the CHECK spec in SQL. In SQL the CHECK expression is a valid search expression (eg. price > 42 AND tag = ‘foo’), and is limited to the current row. Where we differ in Apache Cassan

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

7:47 AM, Jon Haddad wrote: >> >>  >> This looks like a really nice improvement to me. >> >> >> On Thu, Apr 10, 2025 at 7:27 AM Štefan Miklošovič > <mailto:smikloso...@apache.org>> wrote: >> Recently, David Capwell was commenting on constraint

Re: [DISCUSS] How we version our releases

> So here's what I'm thinking: a new release strategy that doesn't use .MINOR > of semver. Goals: So we avoid 6.1, 7.2, etc? Does this imply that each release is allowed to make breaking changes (assuming they followed the “correct” deprecation process)? My first instinct is to not like this,

Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0 Strong +1 to T-3, we should support 4.0/4.1 to 6.0 upgrades. > On Apr 10, 2025, at 2:18 PM, C. Scott Andreas wrote: > > +1 6.0 > > - Scott > > — > Mobile > >> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna wrote: >> >> +1 for 6.0 for TCM/Accord changes, making it easier to make a case

Re: Meaningless emptiness and filtering

Been expanding the current AST Harry tests to include collections and UDTs and been finding even more fun with vs null… what Cassandra returns is a product of the schema and what you do with the table; and these types can act differently than other types. > On Feb 13, 2025, at 4:45 AM, Mick Se

Re: Inconsistent null handling between WHERE and IF clauses

support it, we have to treat NULL like we do in IF - even if > it’s not how we want it to work. > >> On 24 Mar 2025, at 23:45, David Capwell wrote: >> >> In fuzz testing I have found some differences between `WHERE` and `IF` >> clauses that want to get feedback f

Inconsistent null handling between WHERE and IF clauses

In fuzz testing I have found some differences between `WHERE` and `IF` clauses that want to get feedback from the broader community. If you try to query with a `null` we will reject it ``` @Test public void test() throws IOException { try (Cluster cluster = Cluster.build(1).start())

Re: Meaningless emptiness and filtering

Talking in slack I was linked to a Go Client issue (see https://the-asf.slack.com/archives/CK23JSY2K/p1742413507980149?thread_ts=1742409054.164389&cid=CK23JSY2K and https://the-asf.slack.com/archives/C05LPRVNZV1/p1741108083834769 ) gocql was sending empty bytes until recently… > On Mar 19, 20

Re: Welcome Ekaterina Dimitrova as Cassandra PMC member

Congrats! Very deserving! > On Mar 4, 2025, at 3:09 PM, Brandon Williams wrote: > > Congratulations Ekaterina! > > Kind Regards, > Brandon > > On Tue, Mar 4, 2025 at 2:25 PM Paulo Motta wrote: >> >> Aloha, >> >> The Project Management Committee (PMC) for Apache Cassandra is delighted to

Re: Meaningless emptiness and filtering

icit and - as David says - >>> inconsistent. It would be nice to move away from this as the default for a >>> variety of reasons, but also nice to make the behaviour well defined for >>> those use cases we think we’re supporting. >>> >>> On 11 Feb 2025, at 21:16

Re: Meaningless emptiness and filtering

pport, that would preferably NOT match EMPTY >> values for the types where empty means something, like strings. For >> everything else, EMPTY could be equivalent to null and match IS NULL. >> >> The only real way to make SAI compatible with the current behavior is to add >>

Meaningless emptiness and filtering

Bringing this discussion to dev@ rather than Slack as we try to figure out CASSANDRA-20313 and CASSANDRA-19461. In the type system, we have 2 different (but related) methods: AbstractType#allowsEmpty- if the user gives empty bytes (new byte[0]) will the type reject it Ab

Re: [VOTE] CEP-45: Mutation Tracking

+1 > On Feb 3, 2025, at 10:33 AM, Blake Eggleston wrote: > > Hi dev@, > > I’d like to start the voting for CEP-45: Mutation Tracking > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking > Discussion: https://lists.apache.org/thread/0rstj4bzbb2596o5vw

Re: Capabilities

orage/dissemination mechanism, this feels like an > implementation detail. > > Ideally if this is well modularized, we can always plugin or replace it with > other backends (TCM/UDP/S3/morse code/whatever) once this is functional. > > On Wed, Jan 29, 2025 at 1:17 PM David Capw

Re: Capabilities

To be explicit about my concerns in the previous comments… TCM vs new table, I don’t care too much. I prefer TCM over new table, but its a preference My comment before were more about the UX of global configs. As long as we “could” (maybe per config, not every config likely needs this) allow

Re: [DISCUSS] 5.1 should be 6.0

I have not checked Jenkins, but we see this in another environment… For python upgrades have we actually audited the runtime to see that the time spent is doing real work? Josh and I have spent a ton of time trying to fix (and failing) an issue where the python driver blocks the test and we wai

Re: [DISCUSS] synchronisation of properties between Config.java and cassandra.yaml

So if you forget to update cassandra.yaml you fail the build? Makes sense to me. One additional thing I would like to see is the reverse… did you put something in yaml that isn’t in Config? This is a bug I have seen a few times…. Mostly because people don’t know the rules from SnakeYAML so ar

Re: Patrick McFadin joins the PMC

Congrats! > On Jan 22, 2025, at 10:06 AM, Jean-Armel Luce wrote: > > Congratulations, Patrick !! > > Le mer. 22 janv. 2025 à 18:55, Abe Ratnofsky > a écrit : >> Congrats Patrick! Well deserved. >> >>> On Jan 22, 2025, at 11:30, Ekaterina Dimitrova >>

Re: What branches should perf fixes be targeting

I think Paulo and I are in-sync on this. For me 4.x is mostly about stability right now and 5.x is more active development; so I have a higher bar for back ports to 4.x than I do to 5.x. There is also the question on “risk” which can be subjective from reviewer to reviewer. Some patches may be

Incorrectness in SELECT and purged Cells

During fuzz testing of Accord’s CQL integration, we identified an edge case that resulted in an IndexOutOfBoundsException. This issue was reported as CASSANDRA-20108 [1]. Initially, we believed this to be a type-related problem and did not draw attention to it. However, we ensured that the work

Re: [DISCUSS] Usage of "var" instead of types in the code

+1 to allow in tests > On Jan 9, 2025, at 10:58 AM, Caleb Rackliffe wrote: > > +1 to allowing in tests for now > > On Wed, Jan 8, 2025 at 12:51 PM Mick Semb Wever > wrote: >> >> Jumping in, I'm ok to allow it in tests for a trial period too. I would >> imagine in tes

Re: Capabilities

> Stefan, global configuration and capabilities do have some overlap but not > full overlap. For example, you may want to set globally that a cluster > enables feature X or control the threshold for a guardrail but you still need > to know if all nodes support feature X or have that guardrail, t

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

As part of the Accord work we have been extending the harry models to support even more of the CQL domain and added more test coverage for different features; in doing so it found the following query is currently blocked — delete partition if static column is in a given state — confirmed that th

Re: Supporting 2.2 -> 5.0 upgrades

assandra-sidecar), for example JMX Mbeans and other >>> interfaces. >>> >>> I think one way to do that would be to split cassandra-all into >>> cassandra-server and cassandra-common (anything used by both subprojects >>> and server), but not sur

Re: [DISCUSS] 5.1 should be 6.0

> My expectation is that in trunk SCM CASSANDRA_4 would change to SCM > CASSANDRA_5. Assuming you upgrade from 4.0 to 5.0, then you are running on CASSANDRA_4… how many people know that they are expected to do something about that (Sam documented the steps earlier)? What if you leave things al

Re: Supporting 2.2 -> 5.0 upgrades

From a disk format point of view the only thing I remember was the disk type bug with UDTs. Bringing that logic back was hard as the type system (in 5.0) tries to avoid allowing construction of invalid states, and we would need to weaken that in order to enable the migration. Assuming the user

Re: [DISCUSS] 5.1 should be 6.0

Given our version support… if we do make this change does this imply users must do the following to get to 6.0? 4.x upgrade to 5.0 5.0 upgrade to 6.0 So no 4.x to 6.0? Given that this is 5.1 atm we are expected to support 4.x to 5.1 upgrades, but switching to 6.0 that isn’t true based off our

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 > On Nov 5, 2024, at 1:34 PM, Mick Semb Wever wrote: > > > >> As per the CEP process documentation, this vote will be open for 72 hours >> (longer if needed). > > > > > +1

Re: [DISCUSS] Usage of "var" instead of types in the code

I am fine with allow in tests ban in src > On Oct 30, 2024, at 7:16 AM, Štefan Miklošovič wrote: > > https://issues.apache.org/jira/browse/CASSANDRA-20038 > > On Wed, Oct 30, 2024 at 2:40 PM Brandon Williams > wrote: >> Allow in tests, forbid elsewhere is my vote and s

Re: [DISCUSS] Usage of "var" instead of types in the code

I am one of the people using var, and this mostly comes from me doing “int” and having IntelliJ fix it (faster than typing out Future>>>)… so its a faster version for me… Personally I find that while I am writing the code I like var, but as I hone it I tend to remove it to improve readability.

Re: [Discuss] Repair inside C*

> Is there anyway it makes sense for this to be an external process rather than > a new thread pool inside the C* process? One thing to keep in mind is that larger clusters require you “smartly” split the ranges else you nuke your cluster… knowing how to split requires internal knowledge from t

Re: [VOTE] Release Apache Cassandra 5.0.2

+1 > On Oct 16, 2024, at 2:45 PM, Dinesh Joshi wrote: > > +1 > > On Wed, Oct 16, 2024 at 5:19 AM Mick Semb Wever > wrote: >> Proposing the test build of Cassandra 5.0.2 for release. >> >> sha1: f278f6774fc76465c182041e081982105c3e7dbb >> Git: https://github.com/apache/

Re: [DISCUSS] Donating easy-cass-stress to the project

> I think we should just accept easy-cass-stress as a subproject and go > from there. Replacing stress can be handled separately and still has > the large issue of reconciling the build systems that I raised in the > beginning of this thread, but can be figured out eventually. I strongly agree wi

Re: CEP-15: Accord status

7;t think we collectively should be worried about >>> disruption from this patch since: >>> Each commit (or the vast majority?) has already been reviewed by >= 1 other >>> committer >>> 7.3k deletions is a lot less than 42k >>> We now have fuzzin

Re: CEP-15: Accord status

gt; Most of this code is additive >> How would you recommend interested parties engage with reviewing this >> behemoth? Or perhaps subsections of it or key areas to familiarize >> themselves with the structure? >> >> On Fri, Sep 20, 2024, at 12:17 PM, David Capwell wrote: >&

CEP-15: Accord status

Recently, we rebased against the trunk branch, ensuring that the accord branch is now in sync with the latest trunk version. This presents an opportune moment for those interested to review the code. We have a pending pull request (https://github.com/apache/cassandra/pull/3552) that we do not i

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

> I think reserializing the payload into a new format is counter productive to > some of the performance goals of the binary logs? If you have to deserialize > and reserialize the message you are going to be throwing off a ton of extra > GC. That isn’t what happens in FQL =D. FQL creates a cus

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

> Do we need any of these things either? We have our own serialisation > framework and file readers and writers, and at least in the FQL case these > are the native serialisation format. > > At cursory glance it also looks to me like this would be a minimal refactor > from the current state. >

Re: [DISCUSS] CEP-39: Cost Based Optimizer

I am personally in favor of the idea and some of the finer details can be worked around I think. In https://issues.apache.org/jira/browse/CASSANDRA-19769 I added a AST for CQL for tests and improving our testing, which led me to file several tickets as it found bugs…. There is a large part of m

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

I personally don’t mind switching off Chronicle Queue. I have a transformer function to convert the FQL logs to Thrift (don’t judge) and use easy-cas to reply on a cluster… replying FQL from Chronicle Queue was far slower than Thrift and was hard to push the cluster as the client was the bottle

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

> if we are counting on users to read NEWS.txt, can we not count on them to > enable rejection if this is important to them? I think we can make the inverse statement… if accepting data loss is a tradeoff they want then disabling is there for them? So we could default for safety and let you op

Re: Welcome Jordan West and Stefan Miklosovic as Cassandra PMC members!

Congrats to the both of you! > On Aug 30, 2024, at 3:18 PM, Josh McKenzie wrote: > > Congratulations to both of you! > > On Fri, Aug 30, 2024, at 6:11 PM, Leo Toff wrote: >> Congratulations you guys! >> >> >> On Fri, Aug 30, 2024, 2:30 PM Ekaterina Dimitrova > >

Re: Welcome Doug Rohrer as Cassandra Committer

Congrats! > On Aug 23, 2024, at 1:38 PM, Bernardo Botella > wrote: > > Congratulations Doug! > >> On Aug 23, 2024, at 1:20 PM, Yifan Cai wrote: >> >> Congrats Doug! >> From: Jordan West >> Sent: Friday, August 23, 2024 1:19:04 PM >> To: dev@cassandra.apache.org >> Subject: Re: Welcome Doug

Re: CASSANDRA-19835 should block 5.0.0

Merged to 5.0.0 > On Aug 14, 2024, at 2:41 PM, Josh McKenzie wrote: > > This looks like a "merge it to 5.0.0 and re-rev rc" to me. > > On Wed, Aug 14, 2024, at 2:21 PM, David Capwell wrote: >> CASSANDRA-19835 fixes a very small bug but one that has big impact: i

CASSANDRA-19835 should block 5.0.0

CASSANDRA-19835 fixes a very small bug but one that has big impact: if you use trie Memtable and unslabbed_heap_buffers_logged Cassandra will crash on boot! If you use any other Memtable type and SAI you will break every SSTable write…. The patch is up now, its a 1 line code change just adding

Re: [DISCUSS] Removing support for deterministic table IDs

; <mailto:calebrackli...@gmail.com>> wrote: >>>>>> To clarify, my plan was to deprecate in Config/JMX and ignore it, not >>>>>> remove it entirely so it breaks existing YAMLs and JMX clients. >>>>>> >>>>>> This sh

Re: [DISCUSS] Removing support for deterministic table IDs

Users can provide ids and TCM can manage to make them safe, so agree we don’t really need the feature anymore. I am fine with deprecating the feature, but removing would be a breaking change for anyone that had that config in place, so not a fan of breaking the config interface. > On Jul 30, 2

Re: Welcome Joey Lynch as Cassandra PMC member

Congrats! > On Jul 24, 2024, at 10:41 AM, Jon Haddad wrote: > > Congrats Joey! > > On Wed, Jul 24, 2024 at 9:56 AM Francisco Guerrero > wrote: >> Congrats, Joey! >> >> On 2024/07/24 14:12:11 Benjamin Lerer wrote: >> > The PMC's members are pleased to announce that

Re: [DISCUSS] Replace airlift/airline library with Picocli

I am not for or against replacing… > I'm talkingabout CEP-38 [1], where I want to reuse the NodeTool commands and > execute them via CQL > 1. So the first requirement that airline doesn't fulfil is to allow us > to stay aside from all API-specific options of the commands and only > use them whe

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

brary as a project dependency getting any >> objections from the Community? Please, share your thoughts. >> >> There are a few other alternatives (commons-cli, airline2, jcommander) >> but they are not as well known and/or not as elegantly suited to our >> needs based on

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

> I don't personally think there is a strong need for a feature branch. If it > makes it easy for you, please go ahead with a feature branch. Agree, I don’t see the reason for a feature branch… feature branch just means the branch lives in apache domain rather than your own fork. You won’t be

Re: Cassandra PMC Chair Rotation, 2024 Edition

Congrats! > On Jun 20, 2024, at 9:10 AM, Melissa Logan wrote: > > Josh, thank you for your time as chair + congrats Dinesh! > > On Thu, Jun 20, 2024 at 9:08 AM Abe Ratnofsky > wrote: >> Congrats Dinesh! Thank you Josh! >> >>> On Jun 20, 2024, at 11:53 AM, Jeremiah Jordan

Re: [DISCUSS] Stream Pipelines on hot paths

I am cool for forbidding with a callout that tests are ok. I am cool with forbidding in tests as well, but thats just for consistency reasons than anything. > On May 31, 2024, at 8:12 AM, Brandon Williams wrote: > > > On Fri, May 31, 2024 at 9:35 AM Abe Ratnofsky > wrot

Re: [DISCUSS] Stream Pipelines on hot paths

agreement about edge cases, but if anyone in a discussion thinks something is a hot path then it should be treated as one IMO. On 30 May 2024, at 18:39, David Capwell wrote

Re: [DISCUSS] Stream Pipelines on hot paths

As a general statement I agree with you (same for String.format as well), but one thing to call out is that it can be hard to tell what is the hot path and what isn’t. When you are doing background work (like repair) its clear, but when touching something internal it can be hard to tell; this c

Re: [DISCUSS] The way we log

> I saw a lot of cases like this: > > if (logger.isTraceEnabled()) > logger.trace("a log message"); > > and sometimes just: > > logger.trace("a log message"); > > Why do we do it once like that and another time the other way? I remember years ago seeing perf numbers where the i

Re: [DISCUSS] Adding experimental vtables and rules around them

drail. Just a thought. I do not see yet how we could leverage it, just > saying how I perceive it. > > On Wed, May 29, 2024 at 9:02 PM David Capwell <mailto:dcapw...@apple.com>> wrote: >> We agreed a long time ago that all new features are disabled by default, but >>

[DISCUSS] Adding experimental vtables and rules around them

We agreed a long time ago that all new features are disabled by default, but I wanted to try to flesh out what we “should” do with something that might still be experimental and subject to breaking changes; I would prefer we keep this thread specific to vtables as the UX is different for differe

Re: [DISCUSS] Gossip Protocol Change

s that had serious impact (from >> data loss to loss of ability to safely replace nodes in the cluster). >> >> I am happy to contribute some time to this if lack of folks is the issue. >> >> Jordan >> >> On Mon, May 13, 2024 at 17:05 David Capwell >

  1   2   3   4   >