Re: Vector search demo, and query syntax

At first I wasn’t sure about using ORDER BY, but the more I think about what is actually going on, I think it does make sense. This also matches up with some ideas that have been floating around about being able to ORDER BY a sorted SAI index. -Jeremiah > On May 22, 2023, at 2:28 PM, Jonathan

Re: [DISCUSS] Feature branch version hygiene

So what do we do with feature branch merged tickets in this model? They stay on 5.0-target after close and move to 5.0.0 when the epic is merged and closes? > On May 18, 2023, at 9:33 AM, Josh McKenzie wrote: > >> My mental model, though, is that anything that’s not a concrete release >>

Re: [DISCUSS] The future of CREATE INDEX

> [POLL] Centralize existing syntax or create new syntax? 1.) CREATE INDEX ... USING WITH OPTIONS... > [POLL] Should there be a default? (YES/NO) YES > [POLL] What do do with the default? 3.) YAML config to override default index (legacy 2i remains the default) DESCRIBE should always

Re: [VOTE] CEP-29 CQL NOT Operator

+1 nb > On May 8, 2023, at 3:52 AM, Piotr Kołaczkowski wrote: > > Let's vote. > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator > > Piotr Kołaczkowski > e. pkola...@datastax.com > w. www.datastax.com

Re: [DISCUSS] The future of CREATE INDEX

> If we assume SAI is what we should use by default for the cluster, would it > make sense to allow > > CREATE INDEX [IF NOT EXISTS] [name] ON () > > But use a new yaml config that switches from legacy to SAI? > > default_2i_impl: sai > > For 5.0 we can default to “legacy” (new features

Re: [DISCUSS] The future of CREATE INDEX

If the consensus is that SAI is the right default index, then we should just change CREATE INDEX to be SAI, and legacy 2i to be a CUSTOM INDEX. > On May 9, 2023, at 4:44 PM, Caleb Rackliffe wrote: > > Earlier today, Mick started a thread on the future of our index creation DDL > on Slack: >

Re: [POLL] Vector type for ML

> To be clear, I support the general agreement David and Jonathan seem to have > reached. +1 as well. > On May 3, 2023, at 3:07 PM, Caleb Rackliffe wrote: > > To be clear, I support the general agreement David and Jonathan seem to have > reached. > > On Wed, May 3, 2023 at 3:05 PM Caleb

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

> One of the explicit goals of making an official sidecar project was to > try to make it something the project does not break compatibility with > as one of the main issues the third-party sidecars (that handle > distributed control, backup, repair, etc ...) have is they break > constantly

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

hing preventing the solution from working with vnodes >>>> right now, and no assumptions about a 1:1 topology between a token and a >>>> node. However, we don’t, today, have the ability to test vnode support >>>> end-to-end. We are working towards that, however,

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

>> the released analytics library once we can properly test vnode support. >> If it helps, I can update the CEP to say something more like “Caveat: >> Currently untested with vnodes - work is ongoing to remove this limitation” >> if that helps? >> >> Doug >>

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

I have concerns with the majority of this being in the sidecar and not in the database itself. I think it would make sense for the server side of this to be a new service exposed by the database, not in the sidecar. That way it can be able to properly integrate with the authentication and

Re: [EXTERNAL] [DISCUSS] Next release date

Given the fundamental change to how cluster operations work coming from CEP-21, I’m not sure what freezing early for “extra QA time” really buys us? I wouldn’t trust any multi-node QA done pre commit. What “stabilizing” do we expect to be doing during this time? How much of it do we just have

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

> As for precedent - we (including me) have done a lot of stupid shit over the > years on this project. Half the time “this is how we’ve historically done X” > to me is a strong argument to start doing things differently. This is one > such case. +1. I definitely agree that this is one area

Re: [DISCUSS] Change the useage of nodetool tablehistograms

-1 on any change which breaks the previously documented usage. +1 any additions to what the tool can do without breaking previously documented behavior. > On Mar 16, 2023, at 7:42 AM, Josh McKenzie wrote: > > We could also consider augmenting the tool with new named arguments with the >

Re: [DISCUSS] New dependencies with Chronicle-Queue update

Given we need to upgrade to support JDK17 it seems fine to me. The only concern I have is that some of those libraries are already pretty old, for example the most recent jna-platform is 5.13.0 and 5.5.0 is almost 4 years old. I think we should we use the most recent versions of all libraries

Re: [DISCUSS] Enhanced Disk Error Handling

It is actually more complicated than just removing the sstable and running repair. In the face of expired tombstones that might be covering data in other sstables the only safe way to deal with a bad sstable is wipe the token range in the bad sstable and rebuild/bootstrap that range (or

Re: Degradation of availability when using NTS and RF > number of racks

ase where a potentially > QUORUM-busting configuration is used. I think it would be a worse experience > to not warn and let the user discover later when they can't write at QUORUM. > > Cheers, > > Derek > > On Tue, Mar 7, 2023 at 9:32 AM Jeremiah D Jordan <mailto:jeremiah.

Re: Degradation of availability when using NTS and RF > number of racks

I agree with Paulo, it would be nice if we could figure out some way to make new NTS work correctly, with a parameter to fall back to the “bad” behavior, so that people restoring backups to a new cluster can get the right behavior to match their backups. The problem with only fixing this in a

Re: Downgradability

We have multiple tickets about to merge that introduce new on disk format changes. I see no reason to block those indefinitely while we figure out how to do the on disk format downgrade stuff. -Jeremiah > On Feb 22, 2023, at 3:12 PM, Benedict wrote: > > Ok I will be honest, I was fairly

Re: Downgradability

If we can get opt-in major format upgrades, as well as an offline sstabledowngrade tool, I think we have a good first step that would make downgrades possible. Given Jacek’s work on the sstable format API, and the work from Yuki and Claude on old formats, I think we are pretty close to having

Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 nb > On Feb 6, 2023, at 10:15 AM, Sam Tunnicliffe wrote: > > Hi everyone, > > I would like to start a vote on this CEP. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata > > Discussion: >

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

I think we need a DISCUSS thread at minimum for API changes. And for anything changing CQL syntax, I think a CEP is warranted. Even if it is only a small change to the syntax. > On Feb 2, 2023, at 9:32 AM, Patrick McFadin wrote: > > API changes are near and dear to my world. The scope of

Re: Merging CEP-15 to trunk

> "hold the same bar for merges into a feature branch as trunk" I think this is the key point here. If a feature branch is being treated as if it was a release branch with respect to commits that go into it then there should be no need to “do extra review pre merge to trunk”. The feature

Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

+1 nb > On Dec 7, 2022, at 3:40 PM, Mick Semb Wever wrote: > > > Proposing the (second) test build of Cassandra 4.1.0 for release. > > sha1: f9e033f519c14596da4dc954875756a69aea4e78 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative > Maven

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

> 1. I think it is a mistake to offer a function MAX that operates over rows > containing collections, returning the collection with the most elements. This > is just a nonsensical operation to support IMO. We should decide as a > community whether we “fix” this aggregation, or remove it. The

Re: Should we change 4.1 to G1 and offheap_objects ?

At DataStax we’ve been shipping those optional G1 settings as the default for many years now, so I am +1 to at the very least making the change in trunk, but really I would think it fine to make it back in 4.0 and 4.1 as well. -Jeremiah > On Nov 9, 2022, at 1:32 PM, David Capwell wrote: > >

Re: Shall 4.2 become 5.0 ?

So the TL;DR here is that you (Mick) now also agree we should move the version to 5.0? I haven’t seen any other arguments for staying on 4.2, so should we just move the version number to 5.0 now? Do we want to have a VOTE thread for it? Or should we just do it? -Jeremiah > On Oct 16, 2022,

Re: [VOTE] Revising release gating criteria and CI systems

+1 nb > On Oct 8, 2022, at 7:30 AM, Josh McKenzie wrote: > > DISCUSS thread: > https://lists.apache.org/thread/o166v7nr9lxnzdy5511tv40rr9t6zbrw > > > Revise Release Lifecycle cwiki page >

Re: Shall 4.2 become 5.0 ?

If we drop Java 8 support then I would think we need to go to 5.0. That definitely qualifies to me as “this release is not backwards compatible with 4.1”. -Jeremiah > On Sep 26, 2022, at 12:12 PM, Aleksey Yeshchenko wrote: > > Don’t have an opinion on designating 4.2 as 5.0 instead, though

Re: [DISCUSS] CEP-20: Dynamic Data Masking

A > On Sep 7, 2022, at 8:58 AM, Benedict wrote: > > Well, I am not convinced these changes will materially impact the outcome, > but at least we’ll have some extra fun collating the votes. > > >> On 7 Sep 2022, at 14:05, Andrés de la Peña wrote: >> >>  >> The poll makes sense to me. I

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

For ASF project the binary release are always considered as “convenience binaries”, the official release is always just the source artifacts. See the ASF release policy for more information. https://www.apache.org/legal/release-policy.html#compiled-packages

Re: Inclusive/exclusive endpoints when compacting token ranges

Reading the responses here and taking a step back, I think the current behavior of nodetool compact is probably the correct behavior. The main use case I can see for using nodetool compact is someone wants to take some sstable and compact it with all the overlapping sstables. So you run

Re: [DISCUSS] Making a 4.0.5 release

4.0.4 went out mid May, so +1 from me for cutting 4.0.5 soon/now. Should we get into a habit of releasing patch releases on some schedule rather than waiting for someone to randomly ask for a release after committing something they feel is important? -Jeremiah > On Jul 8, 2022, at 10:55 AM,

Re: [DISCUSS] Next release cut

I agree with Josh here. If we can’t be adding things that pass review up until the moment we decide to cut the release it means people are not following our stated goals/process for suitability for merge. If that is the case then we should work to fix that, not add arbitrary soft freeze

Re: [DISCUSS] CASSANDRA-17292 Move cassandra.yaml toward a nested structure around major database concepts

I don’t really care much about what the actual structure ends up being. My main suggestion would be that we do not do anything “incremental” here. I think that would just cause more confusion to have some properties using a new format and some using the current format. There should be some

Re: [DISCUSS] CEP-19: Trie memtable implementation

I don’t really see most users touching the default implementation. I would expect the main reason someone would change would be 1. They run into some bug that is only in one of the implementations. 2. They have persistent memory and so want to use

Re: [VOTE] Release Apache Cassandra 3.11.12

-1 nb for same reason as I said for the 4.0.2 vote here: https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr > On Feb 8, 2022, at 4:10 AM, Dorian ROSSE wrote: > > Hello Scott, > > > Yours links should work but

Re: [VOTE] Release Apache Cassandra 3.0.26

-1 nb for same reason as I said for the 4.0.2 vote here: https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr > On Feb 8, 2022, at 6:15 AM, Mick

Re: [VOTE] Release Apache Cassandra 4.0.2

-1 nb So we just voted on an approved the CI process page recently: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280 Where we said: "All releases by default are expected to have a green test

Re: [DISCUSS] CEP-7 Storage Attached Index

mparison. >>>>>>>>> >>>>>>>>> As long as prefix BTree supports range/prefix aggregation (which is >>>>>>> used >>>>>>>> to >>>>>>>>> speed up >>>>>>>>

Re: Is removal of dead code bug or feature?

As has been previously discussed, the project does not actually define what internal things are meant to be public apis, and what are not. So that is one more reason to consider removal of un-used functions an improvement / not for patch releases. Some third party plugin, for custom indexes,

Re: [VOTE] Formalizing our CI process

I agree with Scott’s sentiments. If we are keeping a green CI then an urgent release with green CI should not be hard. In the worst case you do the “urgent” release as a single commit fix on top of the previous release tag, not by cutting the current dev branch, in that case you should easily

Re: [VOTE] Formalizing our CI process

+1 nb > On Jan 10, 2022, at 1:00 PM, Joshua McKenzie wrote: > > Wiki draft article here: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280 > > > The vote will be open for 72 hours (it's

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

stuff. > On Dec 16, 2021, at 10:29 AM, Jeremiah D Jordan > wrote: > > If we want to have “called out development snapshots” then I think we need > some way to distinguish build from those commits the from ongoing work in the > version number that is in the build fil

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

If we want to have “called out development snapshots” then I think we need some way to distinguish build from those commits the from ongoing work in the version number that is in the build file. I do not think the “development snapshots” being 4.1.0-SNAPSHOT and current trunk also being

Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection

If it is per query, then I would think protocol level might be easier to “test” a given application with. Rather than having to append "WITH ADDITIONAL LATENCY” to all your queries, you just set some option in your query based object or such. We already have support at the protocol level for

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> On Nov 15, 2021, at 2:25 PM, Stefan Miklosovic > wrote: > > On Mon, 15 Nov 2021 at 19:42, Jeremiah D Jordan > mailto:jeremiah.jor...@gmail.com>> wrote: >> >> >> >>> On Nov 14, 2021, at 3:53 PM, Stefan Miklosovic >>&g

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> On Nov 14, 2021, at 3:53 PM, Stefan Miklosovic > wrote: > > Hey, > > there are two points we are not completely sure about. > > The first one is streaming. If there is a cluster of 5 nodes, each > node has its own unique encryption key. Hence, if a SSTable is stored > on a disk with the

Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA-17056)

ould be as simple as an annotation like >> @ExposedTo3rdParties (Hadoop does this to show an interface is exposed and >> must be maintained), or it could be something like split directories >> (src/java = private, src/java-exposed = public); I am trying not to dictate >

Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA-17056)

We already have many interfaces similar to these for Compaction Strategy, Indexing, Query Handler. I would hope that commiters are already following a policy along the lines of trunk -> anything goes, not trunk -> try not to change these interfaces. I would expect that to be the same policy

Re: [DISCUSS] CEP-18: Improving Modularity

, 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

Re: [DISCUSS] CEP-18: Improving Modularity

their own right. > > I air all this just to contribute perspective to the discussion; all that > said, I think refactoring APIs as a pure reflection of what the DB is doing > today just risks ossifying something that grew up organically and probably > isn't going to do us any favors, so havin

Re: [DISCUSS] CEP-18: Improving Modularity

As Henrik said we have been refactoring access to these different internal APIs as part of some larger work. For this CEP we pulled together a bunch of the smaller ones into one place, similar to the refactoring proposed in CEP-10, as we felt doing many small CEPs, one per module, would be

Re: [DISCUSS] CASSANDRA-16922 CEP-10: Major Prerequisites (Phase 1)

> As these progress through review, the aim is to roll them up into a single > branch and merge that to trunk together, keeping the separate commits for the > specific JIRAs. I think this is a great idea. Where do you see the “Roll Up Branch” living? Does the project want to start keeping

Re: [DISCUSS] CASSANDRA-15234

> Also, if you run the above command you will see we actually have a lot of > things show (129 lines)… it would be nice to clean it up as only a small > subset is required and most shown normal users won’t care +1 for this. It would be good to clean up the config code and yaml such that only

Re: Cassandra CI Systems confluence page

+1 from me. There is a lot of good info on that page, no need to keep it draft that I can see. > On Aug 9, 2021, at 1:00 AM, Mick Semb Wever wrote: > > Any objections if this confluence page comes out of draft? > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=153815764 > >

Re: [DISCUSS] Diagnostic events in virtual tables

Yes, I think it would make sense to have the events available in a virtual table, especially if we are trying to move our operational management in that direction. But, why does it need to be bin log or virtual tables? Why not both? The virtual tables could even return the data stored in the

Re: [DISCUSS] CEP-11: Pluggable memtable implementations

+1 from me. I like the direction many of these proposals are going to clean up/add internal interfaces along with the new features proposed. -Jeremiah > On Jul 20, 2021, at 1:27 PM, bened...@apache.org wrote: > > I think it would be a mistake to combine the Memtable with CommitLog; several >

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

+1 from me for the proposal ignoring the "where it goes". I think the refactors proposed in it make sense no matter what, and the simulation ability should provide some very much needed testability improvements. In particular replacing File with Path is something we have been looking to do

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

duces the highest quality outcome. > > > > > From: Jeremiah D Jordan > Date: Tuesday, 13 July 2021 at 14:41 > To: Cassandra DEV > Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations > I do not think fixing CASSANDRA-12126 is not a new feature. I do think > a

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

Too many nots. I do not think fixing 12126 is a new feature. > On Jul 13, 2021, at 8:40 AM, Jeremiah D Jordan wrote: > > I do not think fixing CASSANDRA-12126 is not a new feature. I do think > adding the ability to do “Cluster and Code Simulations” is a new feature. &g

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

only would it be burdensome (given the divergences in > the codebase), but I would not consider it acceptably safe (given the > divergence). > > > From: Jeremiah D Jordan > Date: Tuesday, 13 July 2021 at 14:15 > To: Cassandra DEV > Subject: Re: [DISCUSS] CEP-10: Clust

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

I tend to agree with Paulo that a major refactoring of some internal interfaces sounds like something to be explicitly avoided in a patch release. I thought this was the type of change we all agreed we should stop letting in to patch releases, and that we would attempt to release more often

Re: [DISCUSSION] Should we mark DROP COMPACT STORAGE as experimental

We had many discussions around this back when this was added. There is a transition ability in place. Users can set a native protocol flag to have the server return results as if DROP COMPACT STORAGE was already run. In this way you can update your applications to support the new way results

Re: [DISCUSS] Semantic versioning after 4.0

+1 for doing this (or something similar). It will give more clarity to downstream users about the compatibility of a given release. -Jeremiah > On Apr 30, 2021, at 12:45 PM, Mick Semb Wever wrote: > > *** Proposal *** > Aligned to the agreed-upon annual cadence of supported releases, let's >

Re: [DISCUSS] Releases after 4.0

I think we are confusing things between minor vs patch. Can we talk about branch names? I think we can agree on the following statements? Releases made from stable maintenance branches, cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit features being added to them and

Re: Welcome Jordan West, David Capwell, Zhao Yang and Ekaterina Dimitrova as Cassandra committers

Congratulations everyone! Good to see the project getting new committers. > On Dec 16, 2020, at 10:55 AM, Benjamin Lerer > wrote: > > The PMC's members are pleased to announce that Jordan West, David Capwell, > Zhao Yang and Ekaterina Dimitrova have accepted the invitations to become >

Re: [DISCUSS] Future of MVs

> So from my PoV, I'm against us just voting to deprecate and remove without > going into more depth into the current state of things and what options are > on the table, since people will continue to build MV's at the client level > which, in theory, should have worse correctness and performance

Re: [VOTE] Project governance wiki doc

I think we need to assume positive intent here. If someone says they will participate then we need to assume they are true to their word. While the concerns are not un-founded, I think the doc as is gives a good starting point for trying this out without being too complicated. If this turns

Re: [VOTE] Project governance wiki doc

+1 non-binding. Thanks for the work on this! > On Jun 16, 2020, at 11:31 AM, Jeff Jirsa wrote: > > +1 (pmc, binding) > > > On Tue, Jun 16, 2020 at 9:19 AM Joshua McKenzie > wrote: > >> Added unratified draft to the wiki here: >> >>

Re: [DISCUSS] CASSANDRA-13994

mostly a way of saying: >> – I like the cadence/sequencing Benedict proposes below. >> – I think improvements in test engineering can reduce/eliminate >> invalidation and may increase the scope of what can be a candidate for >> merge on a given branch >> – And if not, the

Re: [DISCUSS] CASSANDRA-13994

+1 strongly agree. If we aren’t going to let something go into 4.0.0 because it would "invalidate testing” then we can not let such a thing go into 4.0.1 unless we plan to re-do said testing for the patch release. > On May 27, 2020, at 1:31 PM, Benedict Elliott Smith > wrote: > > I'm being

Re: Simplify voting rules for in-jvm-dtest-api releases

I think as long as we don’t publish the artifacts to maven central or some other location that is for “anyone” we do not need a formal release. Even then since the artifact is only meant for use by people developing C* that might be fine. If artifacts are only for use by individuals actively

Re: [Discuss] num_tokens default in Cassandra 4.0

+1 for 8 + algorithm assignment being the default. Why do we have to assume random assignment? If someone turns off algorithm assignment they are changing away from defaults, so they should also adjust the num tokens. -Jeremiah > On Feb 18, 2020, at 1:44 AM, Mick Semb Wever wrote: > > -1 >

Re: Audit logging to tables.

AFAIK the Full Query Logging binary format was already made more general in order to support using that format for the audit logging. -Jeremiah > On Mar 1, 2019, at 11:38 AM, Joshua McKenzie wrote: > > Is there a world in which a general purpose, side-channel file storage > format for

Re: Deprecating/removing PropertyFileSnitch?

hli wrote: > > No worries...I mentioned the issue not the JIRA number > >> On Oct 22, 2018, at 8:01 PM, Jeremiah D Jordan wrote: >> >> Sorry, maybe my spam filter got them or something, but I have never seen a >> JIRA number mentioned in the thread before thi

Re: Deprecating/removing PropertyFileSnitch?

view of this host will be wrong. >>>>>>> >>>>>>> Won't this happen even with PropertyFileSnitch as the token(s) for >> this >>>>>>> host will be missing from gossip/system.peers? >>>>>>> >>>>>>> Em

Re: Deprecating/removing PropertyFileSnitch?

As long as we are correctly storing such things in the system tables and reading them out of the system tables when we do not have the information from gossip yet, it should not be a problem. (As far as I know GPFS does this, but I have not done extensive code diving or testing to make sure all

Re: Moving tickets out of 4.0 post freeze

So as to not confuse people, even if we never put out a 4.1, I think we should keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x. And yes our .. versioning of the past never followed semver. -Jeremiah > On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith > wrote: > > I’d like to propose we

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

ugmenting the scope of a project makes it >>>>> better: >>>>>> I feel >>>>>> keeping this project focused on the core server is better. I see >> risks >>>>>> here, but >>>>>> the upsides haven't been made v

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

No, doesn’t change it. Any code donation has to go through the incubation process, which is where all the legal stuff about it being donated is handled. This would be like the dtest repo which was donated a little while back, and followed this same process. -Jeremiah > On Sep 12, 2018, at

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

+1 But I also think getting this through incubation might take a while/be impossible given how large the contributor list looks… > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa wrote: > > +1 > > (Incubation looks like it may be challenging to get acceptance from all > existing contributors,

Re: UDF

Be careful when pulling in source files from the DataStax Java Driver (or anywhere) to make sure and respect its Apache License, Version 2.0 and keep all Copyright's etc with said files. -Jeremiah > On Sep 11, 2018, at 12:29 PM, Jeff Jirsa wrote: > > +1 as well. > > On Tue, Sep 11, 2018 at

Re: Side Car New Repo vs not

I think the following is a very big plus of it being in tree: >> * Faster iteration speed in general. For example when we need to add a >> new >> JMX endpoint that the sidecar needs, or change something from JMX to a >> virtual table (e.g. for repair, or monitoring) we can do all changes >>

Re: Proposing an Apache Cassandra Management process

Not sure why the two things being in the same repo means they need the same release process. You can always do interim releases of the management artifact between server releases, or even have completely decoupled releases. -Jeremiah > On Aug 17, 2018, at 10:52 AM, Blake Eggleston wrote: >

Re: GitHub PR ticket spam

Oh nice. I like the idea of keeping it but moving it to the worklog tab. +1 on that from me. > On Aug 6, 2018, at 5:34 AM, Stefan Podkowinski wrote: > > +1 for worklog option > > Here's an example ticket from Arrow, where they seem to be using the > same approach: >

Re: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

The community of people doing python development and the community of people running Cassandra servers are not the same. I am not fine riding the coat tails of libraries used in python development. As others have stated we need to be following the lead of the OS vendors that people will be

Re: Evolving the client protocol

The protocol does already support optional/custom payloads to do such things. IIRC the zipkin tracing implementation https://github.com/thelastpickle/cassandra-zipkin-tracing for example uses this to pass the zipkin id to the server. > On Apr 20, 2018, at 1:02 PM, Max C.

Re: Paying off tech debt and correctly naming things

+1 if you are willing to take it on. As the person who performed the Table->Keyspace rename of 2.0, I say good luck! From hindsight of doing that, as others suggested, I would come at this in multiple tickets. I would suggest a simple class rename with intellij refactoring tools or something

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

> Stefan's elastic search link is rather interesting. Looks like they are > compiling for both a LTS version as well as the current OpenJDK. They > assume some of their users will stick to a LTS version and some will run > the current version of OpenJDK. > > While it's extra work to add JDK

Re: Debug logging enabled by default since 2.2

People seem hung up on DEBUG here. The goal of CASSANDRA-10241 was to clean up the system.log so that it a very high “signal” in terms of what was logged to it synchronously, but without reducing the ability of the logs to allow people to solve problems and perform post mortem analysis of

Re: Expensive metrics?

re: nanoTime vs currentTimeMillis there is a good blog post here about the timing of both and how your choice of Linux clock source can drastically effect the speed of the calls, and also showing that in general on linux there is no perf improvement for one over the other.

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

s/does affect/does not affect/ > On Feb 13, 2018, at 11:57 AM, Jeremiah D Jordan <jeremiah.jor...@gmail.com> > wrote: > > I don’t think we need to stop the vote. This CVE has been around for a while > (3/13/2017), and does affect any install I have ever seen. It affects

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

I don’t think we need to stop the vote. This CVE has been around for a while (3/13/2017), and does affect any install I have ever seen. It affects users who manually enable some specific logback features using the SocketServer or ServerSocketReceiver component which are not used in our

Re: URGENT: CASSANDRA-14092 causes Data Loss

If you aren’t getting an error, then I agree, that is very bad. Looking at the 3.0 code it looks like the assertion checking for overflow was dropped somewhere along the way, I had only been looking into 2.1 where you get an assertion error that fails the query. -Jeremiah > On Jan 25, 2018,

Re: V5 as a protocol beta version in 3.11

My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol for tick/tock stuff and known that when a new version came out it would most possibly break the older releases V5 beta stuff? Or at the very least add new things to V5. So I see no reason to need to add more new features

Re: Proposal to retroactively mark materialized views experimental

So for some perspective here, how do users who do not get the guarantees of MV’s implement this on their own? They used logged batches. Pseudo CQL here, but you should get the picture: If they don’t ever update data, they do it like so, and it is pretty safe: BEGIN BATCH INSERT tablea blah

Re: Proposal to retroactively mark materialized views experimental

e sitting >>>> there in the base code but forbidden from version xxx onward. >>>> >>>> Since when do we start removing feature in a patch release ? >> (forbidding >>> to >>>> create new MV == removing t

Re: [VOTE] Release Apache Cassandra 3.11.1

Jeff, TL;DR 3.11.0 shows it for them as well. See https://issues.apache.org/jira/browse/CASSANDRA-13900 for the rest of the story. -Jeremiah > On Oct 2, 2017, at 4:47 PM, Jeff Jirsa wrote: > > Thomas, did you see

Re: Proposal to retroactively mark materialized views experimental

. > > — > AY > > On 2 October 2017 at 18:18:52, Jeremiah D Jordan (jeremiah.jor...@gmail.com) > wrote: > > These things are live on clusters right now, and I would not want someone to > upgrade their cluster to a new *patch* release and suddenly someth

  1   2   >