Re: [VOTE][IP CLEARANCE] Spark-Cassandra-Connector

+1 Le mar. 18 mars 2025 à 19:02, Bernardo Botella a écrit : > +1 (nb) > > On Mar 18, 2025, at 10:52 AM, Yifan Cai wrote: > > +1 (nb) > > -- > *From:* Jeremiah Jordan > *Sent:* Tuesday, March 18, 2025 10:32:14 AM > *To:* dev@cassandra.apache.org > *Cc:* gene...@incu

Re: Welcome Caleb Rackliffe to the PMC

Congratulations! Le sam. 22 févr. 2025 à 13:41, Dmitry Konstantinov a écrit : > Congratulations Caleb! > > On Fri, 21 Feb 2025 at 23:21, Yifan Cai wrote: > >> Congrats Caleb! >> -- >> *From:* Štefan Miklošovič >> *Sent:* Friday, February 21, 2025 11:44:42 AM >> *To:

Re: Welcome Jeremiah Jordan to the PMC

Congrats! Le lun. 17 févr. 2025 à 17:50, Christopher Bradford a écrit : > Well done JD! > > On Feb 17, 2025, at 7:08 AM, Piotr Kołaczkowski > wrote: > > Congrats Jeremiah! > > Wiadomość napisana przez Berenguer Blasi w > dniu 17.02.2025, o godz. 07:23: > > Congrats JD!! :-) > On 16/2/25 20:52,

Re: [DISCUSS] Index selection syntax for CASSANDRA-18112

I am personally -1 against the approach taken by DS for optimizing SAI queries. I consider it as a quick fix rather than a proper long term solution. The issue with this approach is that it splits the optimisation logic of queries. With one part of the optimization happening on the coordinator whil

Re: [VOTE] CEP-43: Apache Cassandra CREATE TABLE LIKE

+1 Le ven. 8 nov. 2024 à 18:31, Yifan Cai a écrit : > +1 (nb) > > - Yifan > > On Thu, Nov 7, 2024 at 10:31 PM guo Maxwell wrote: > >> Thanks Stefan and Dinesh. Let's wait a little longer. >> >> >> Dinesh Joshi 于2024年11月7日周四 23:56写道： >> >>> Maxwell, here's the documentation for project governan

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

I recently faced some var usage in the CQL layer part where it was making the code pretty hard to understand. I am in favor of prohibiting it. Le mar. 29 oct. 2024 à 20:32, Caleb Rackliffe a écrit : > Josh's example of "good" usage seems defensible, because the declared type > is already obfusca

Re: Welcome Chris Bannister, James Hartig, Jackson Flemming and João Reis, as cassandra-gocql-driver committers

Congratulation! Le ven. 13 sept. 2024 à 14:21, Josh McKenzie a écrit : > Congratulations and welcome! It's great to have you all on board! > > On Thu, Sep 12, 2024, at 11:16 PM, guo Maxwell wrote: > > Congratulations! > > James Hartig 于2024年9月13日周五 08:11写道： > > > Thanks everyone! Excited to con

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

Congratulation!!! Le lun. 2 sept. 2024 à 08:14, Berenguer Blasi a écrit : > Congrats both! > > On 1/9/24 15:27, Maxim Muzafarov wrote: > > Сongrats Jordan and Stefan. > > Great work! > > > > On Sun, 1 Sept 2024 at 12:46, guo Maxwell wrote: > >> Congrats Stefan and Jordan!!! > >> > >> Jacek Lewa

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

I think that one important part will be to define the boundaries of the copy. For example, will it also copy the indexes and the Materialized views or only the table schema. Can it be done in a different keyspace? If yes, how about the UDTs if the table uses some? I do not have an opinion. Just rai

Welcome Joey Lynch as Cassandra PMC member

The PMC's members are pleased to announce that Joey Lynch has accepted the invitation to become a PMC member. Thanks a lot, Joey, for everything you have done for the project all these years. Congratulations and welcome The Apache Cassandra PMC members

Re: [VOTE][IP CLEARANCE] GoCQL driver

+1 Le mer. 26 juin 2024 à 08:39, Ekaterina Dimitrova a écrit : > +1 > > On Wed, 26 Jun 2024 at 6:14, Jon Haddad wrote: > >> +1. >> >> On Wed, Jun 26, 2024 at 1:50 AM J. D. Jordan >> wrote: >> >>> +1 nb. Good to see this heavily used driver get continued development in >>> the project. >>> >>>

Re: [DISCUSS] Increments on non-existent rows in Accord

> > Doesn’t an UPDATE statement creates a row if the partition key does not > exist? Things are more tricky that what the documentation is letting people believe. Internally, UPDATE does not really create a row. It creates a set of updates for a row. At the CQL level it looks like a row exists b

[DISCUSS] LWT conditions behavior on collections is inconsistent (CASSANDRA-19637)

Hi everybody, I wanted to raise attention to CASSANDRA-19637 that I already mentioned in the "[DISCUSS] NULL handling and the unfrozen collection issue" thread. The patch attempts to fix some inconsistencies in the way LWT conditions work wi

Re: [DISCUSS] Stream Pipelines on hot paths

For me the definition of hot path is too vague. We had arguments with Berenger multiple times and it is more a waste of time than anything else at the end. If we are truly concerned about stream efficiency then we should simply forbid them. That will avoid lengthy discussions about what constitute

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.1 (2nd attempt)

+1 Le jeu. 23 mai 2024, 21:30, Brandon Williams a écrit : > +1 > > Kind Regards, > Brandon > > On Tue, May 21, 2024 at 5:59 PM Bret McGuire > wrote: > > > >Greetings all! We're going to give this another go. > > > >Apologies for the confusion that sprang out of our last attempt. It >

Re: [DISCUSS] NULL handling and the unfrozen collection issue

cate LWT col = NULL syntax, do we really want people rewriting > those LWTs...or just moving to the new Accord syntax, which obviously > supports it? We should "spend" our user query rewrite budget wisely.) > > On Thu, Apr 4, 2024 at 4:53 AM Benjamin Lerer wrote: > >> N

Re: [DISCUSS] Adding support for BETWEEN operator

values. It >> gives me a headache by just thinking about it. >> >> Ranged delete is much simpler, because the "value" is the same tombstone >> marker, and it also is guaranteed to expire and disappear eventually, so >> the performance impact of dealing wit

Re: [DISCUSS] Adding support for BETWEEN operator

range tombstone, other than probably needing a > version bump of the storage format? > > > On Tue, May 14, 2024 at 12:03 AM Benjamin Lerer wrote: > >> Range restrictions (>, >=, =<, < and BETWEEN) do not work on UPDATEs. >> They do work on DELETE because under

Re: [DISCUSS] Adding support for BETWEEN operator

nk the only project I had as a high school senior > was figuring out how many parties I could go to and still maintain a > passing grade. Thanks for your work here. > > Patrick > > On Mon, May 13, 2024 at 1:35 AM Benjamin Lerer wrote: > >> Hi everybody, >> >>

[DISCUSS] Adding support for BETWEEN operator

Hi everybody, Just raising awareness that Simon is working on adding support for the BETWEEN operator in WHERE clauses (SELECT and DELETE) in CASSANDRA-19604. We plan to add support for it in conditions in a separate patch. The patch is available. As a side note, Simon chose to do his highschool

Welcome Alexandre Dutra, Andrew Tolbert, Bret McGuire, Olivier Michallat as Cassandra Committers

The Apache Cassandra PMC is pleased to announce that Alexandre Dutra, Andrew Tolbert, Bret McGuire and Olivier Michallat have accepted the invitation to become committers on the java driver sub-project. Thanks for your contributions to the Java driver during all those years! Congratulations and w

Re: [DISCUSS] NULL handling and the unfrozen collection issue

ull means deleting it and if *all*​ > columns in a row are null the row is deleted. This might be another edge > case... > > German > ------ > *From:* Benjamin Lerer > *Sent:* Wednesday, March 20, 2024 9:15 AM > *To:* dev@cassandra.apache.org > *S

[DISCUSS] CQL handling of WHERE clause predicates

Hi everybody, CQL appears to be inconsistent in how it handles predicates. One type of inconsistencies is that some operators can be used in some places but not in others or on some expressions but not others. For example: - != can be used in LWT conditions but not elsewhere - Token expres

[DISCUSS] NULL handling and the unfrozen collection issue

Hi everybody, CEP-29 (CQL NOT Operator) is hitting the grey area of how we want as a community to handle NULL including for things like unfrozen (multi-cell) collections and I would like to make a proposal for moving forward with NULL related issues. We have currently 2 tickets open about NULL ha

Re: Welcome Maxim Muzafarov as Cassandra Committer

I am always late to the party. ;-) Congrats Maxim! Le mar. 9 janv. 2024 à 13:16, Maxim Muzafarov a écrit : > Thank you all so much, I'm happy to be part of such an active > community and to be able to contribute to the product that is used all > over the world! > > On Tue, 9 Jan 2024 at 12:33,

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

tness > statistics that are proposed in the CEP. It would be very valuable to > surface query cost to users independent of a CBO. Stats like these would > also be valuable toward retrofitting Cassandra for multitenancy by bounding > or rate-limiting users on query cost. Tracking SSTable h

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

uld > also be valuable toward retrofitting Cassandra for multitenancy by bounding > or rate-limiting users on query cost. Tracking SSTable hotness would also > be useful toward evaluating feasibility of tiered storage, too. > > Thanks for this proposal and discussion so far — appreciat

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

n on some arbitrary schedule > for every replica. > > On 20 Dec 2023, at 15:52, Benjamin Lerer wrote: > >  > >> If we are to address that within the CEP itself then we should discuss it >> here, as I would like to fully understand the approach as well as how it >>

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

scuss more concretely how the base statistics > themselves will be derived, as there is little detail here today in the > proposal. > > On 20 Dec 2023, at 12:58, Benjamin Lerer wrote: > >  > After the second phase of the CEP, we will have two optimizer > implementations.

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

ld preserve the current > robustness of the system while making it at least a touch more configurable. > > On Fri, Dec 15, 2023, at 11:03 AM, Chris Lohfink wrote: > > Thanks for time in addressing concerns. At least with initial versions, as > long as there is a way to replace it w

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

t;>> >>> > The client side proposal targets consistency for a given query on a >>> given driver instance. In practice, it would be possible to have 2 similar >>> queries with 2 different execution plans on the same driver >>> >>> >>> This w

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

ice, it would be possible to have 2 similar >> queries with 2 different execution plans on the same driver >> >> >> This would only be possible if the driver permitted it. A driver could >> (and should) enforce that it only permits one query plan per query. >> >> >&

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

gt;> This would only be possible if the driver permitted it. A driver could >> (and should) enforce that it only permits one query plan per query. >> >> >> The opposite is true for your proposal: some queries may begin degrading >> because they touch speci

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

at translates this > abstract representation into the object graph that executes it. > > If I’m incorrect, could you please elaborate more specifically how you > intend to go about this? > > On 14 Dec 2023, at 10:33, Benjamin Lerer wrote: > >  > >> I mean that

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

2023 à 10:24, Benjamin Lerer a écrit : > Can you share the reasons why Apache Calcite is not suitable for this case >> and why it was rejected > > > My understanding is that Calcite was made for two main things: to help > with optimizing SQL-like languages and to let peopl

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

t on another system that everyone would have to learn and adjust to. The problems and extra work this would bring don't seem worth the benefits we might get Le mer. 13 déc. 2023 à 18:06, Benjamin Lerer a écrit : > One thing that I did not mention is the fact that this CEP is only a high >

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

;> I have a question. Is it easy to turn off cbo's optimizer or by pass in >> some way? Because some simple read and write requests will have better >> performance without cbo, which is also the advantage of Cassandra compared >> to some rdbms. >> >>

[DISCUSS] CEP-39: Cost Based Optimizer

Hi everybody, I would like to open the discussion on the introduction of a cost based optimizer to allow Cassandra to pick the best execution plan based on the data distribution.Therefore, improving the overall query performance. This CEP should also lay the groundwork for the future addition of

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.0

+1 Le lun. 11 déc. 2023 à 19:54, Brandon Williams a écrit : > +1 > > Kind Regards, > Brandon > > On Sat, Dec 9, 2023 at 1:43 AM Mick Semb Wever wrote: > > > > Proposing the test build of Cassandra Java Driver 4.18.0 for release. > > > > sha1: 105d378fce16804a8af4c26cf732340a0c63b3c9 > > Git: ht

Welcome Mike Adamson as Cassandra committer

The PMC members are pleased to announce that Mike Adamson has accepted the invitation to become committer. Thanks a lot, Mike, for everything you have done for the project. Congratulations and welcome The Apache Cassandra PMC members

Re: [VOTE] Release Apache Cassandra 5.0-beta1 (take2)

+1 Le mar. 5 déc. 2023 à 12:23, Maxim Muzafarov a écrit : > +1 (nb) > > run locally, executed some queries over vts > > On Mon, 4 Dec 2023 at 15:15, Brandon Williams wrote: > > > > +1 > > > > Kind Regards, > > Brandon > > > > On Fri, Dec 1, 2023 at 7:32 AM Mick Semb Wever wrote: > > > > > > >

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

Congratulations!!! Well deserved! Le mer. 29 nov. 2023 à 07:31, Berenguer Blasi a écrit : > Welcome! > On 29/11/23 2:24, guo Maxwell wrote: > > Congrats! > > Jacek Lewandowski 于2023年11月29日周三 06:16写道： > >> Congrats!!! >> >> wt., 28 lis 2023, 23:08 użytkownik Abe Ratnofsky napisał: >> >>> Congra

Re: [VOTE] Release Apache Cassandra 5.0-beta1

-1 based on the problems raised by Caleb. I would be fine with releasing that version as an alpha as Jeremiah proposed. As of this time, I'm also not aware of a user of the project operating a > build from the 5.0 branch at substantial scale to suss out the operational > side of what can be expec

Re: [DISCUSS] Harry in-tree

+1 Le lun. 27 nov. 2023 à 18:01, Brandon Williams a écrit : > I am +1 on including Harry in-tree. > > Kind Regards, > Brandon > > On Fri, Nov 24, 2023 at 9:44 AM Alex Petrov wrote: > > > > Hi everyone, > > > > With TCM landed, there will be way more Harry tests in-tree: we are > using it for ma

Re: [VOTE] Release Apache Cassandra 5.0-beta1

Looking at the board it is unclear to me why CASSANDRA-19011 , CASSANDRA-19018 , CASSANDRA-18796 and CASSANDRA-18940

Re: CEP-21 - Transactional cluster metadata merged to trunk

Hi, I must admit that I have been surprised by this merge and this following email. We had lengthy discussions recently and the final agreement was that the requirement for a merge was a green CI. I could understand that for some reasons as a community we could wish to make some exceptions. In thi

Re: Road to 5.0-GA (was: [VOTE] Release Apache Cassandra 5.0-alpha2)

safe. > > > > Do I need permission to view this link? When I open it, an error appears, > saying “It may have been deleted or you don't have permission to view it.” > > Benjamin Lerer mailto:b.le...@gmail.com>> > 于2023年11月6日周一 18:34写道： > I created a Dashboar

Re: Road to 5.0-GA (was: [VOTE] Release Apache Cassandra 5.0-alpha2)

I created a Dashboard to track the progress and remaining tasks for 5.0: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=593 Everybody logged in should have access. Ping me if it is not the case. Le sam. 4 nov. 2023 à 19:54, Mick Semb Wever a écrit : > > Please mark such bugs wit

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

our usual things of two committer +1 and > green CI etc. > > If we are not ready to commit then I propose that as long as everything in > the accord+tcm Apache repo branch has had two committer +1’s, but maybe > people are still working on fixes for getting CI green or similar, we c

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

ski wrote: > > I've been thinking about this and I believe that if we ever decide to > delay a release to include some CEPs, we should make the plan and status of > those CEPs public. This should include publishing a branch, creating > tickets for the remaining work required for fe

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

th only TCM and Accord will reach GA > quickly. Based on the time it took us to release 4.1, I am simply expecting > more delays (a GA around end of May, June). In which case it seems to me > that we could be interested in shipping more stuff in the meantime > (thinking of CASSANDRA-15254 or

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

s to me that we could be interested in shipping more stuff in the meantime (thinking of CASSANDRA-15254 or CEP-29 for example). I do not have a strong opinion, I just want to make sure that we all share the same understanding and fully understand what we agree upon. Le jeu. 26 oct. 2023 à 10:59, Be

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

o do so, so it won't be getting forgotten or > down-prioritised. > > > > On Wed, 25 Oct 2023 at 18:07, Jeremiah Jordan > wrote: > >> If we do a 5.1 release why not take it as an opportunity to release more >>> things. I am not saying that we will. Just that we

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

The proposal includes 3 things: 1. Do not include TCM and Accord in 5.0 to avoid delaying 5.0 2. The next release will be 5.1 and will include only Accord and TCM 3. Merge TCM and Accord right now in 5.1 (making an initial release) I am fine with question 1 and do not have a strong opinion on whic

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

My biggest concern with the 5.1 suggestion is that it makes the review of TCM far more complicated than it should be. Even if all TCM patches were fully reviewed by committers that I fully trust, due to the patch size and the impact of the changes it feels safer to me to have a second round of revi

Re: [DISCUSS] putting versions into Deprecated annotations

Ok, thanks Stefan I understand the context better now. Looking at the PR. Some make sense also for serialization reasons but some make no sense to me. Le ven. 13 oct. 2023 à 14:26, Benjamin Lerer a écrit : > I’ve been told in the past not to remove public methods in a patch release >&g

Re: [DISCUSS] putting versions into Deprecated annotations

inks or > open attachments unless you recognize the sender and know the content is > safe. > > > > > > On Fri, 13 Oct 2023 at 13:07, Benjamin Lerer ble...@apache.org>> wrote: > I was asking because outside of configuration parameters and JMX calls, > the appro

Re: [DISCUSS] putting versions into Deprecated annotations

re was some > solid guidance on this. > > ____ > From: Benjamin Lerer > Sent: Friday, October 13, 2023 13:07 > To: dev@cassandra.apache.org > Subject: Re: [DISCUSS] putting versions into Deprecated annotations > > NetApp Security WARNING: This is an exte

Re: [DISCUSS] putting versions into Deprecated annotations

ault true). After we map what technical debt we > have, we can summarize this and I bring it to the ML again for further > discussion what to actually remove and when. > > Regards > > > From: Benjamin Lerer > Sent: Friday, October 13, 20

Re: [DISCUSS] putting versions into Deprecated annotations

I am a bit confused by the starting point of this discussion: "When we deprecate APIs / methods" What are we exactly calling APIs/methods? It is really unclear to me what we are talking about here. Le jeu. 12 oct. 2023 à 02:38, Francisco Guerrero a écrit : > > > On 2023/10/11 16:59:35 Maxim Muza

Re: [VOTE] Accept java-driver

+1 Le jeu. 5 oct. 2023 à 13:46, Aleksey Yeshchenko a écrit : > +1 > > On 5 Oct 2023, at 10:35, Benedict wrote: > > Surely it needs to be shared with the foundation and the PMC so we can > verify? Or at least have ASF legal confirm they have received and are > satisfied with the tarball? It cert

[DISCUSS] Vector type and empty value

Hi everybody, I noticed that the new Vector type accepts empty ByteBuffer values as an input representing null. When we introduced TINYINT and SMALLINT (CASSANDRA-895) we started making types non -emptiable. This approach makes more sense to me as having to deal with empty value is error prone in

Re: [VOTE] Release Apache Cassandra 5.0-alpha1 (take3)

+1 Le jeu. 7 sept. 2023 à 13:53, Jacek Lewandowski a écrit : > Mick, is the documentation / website ok? > > If so, +1 > > Best Regards, > - - -- --- - - > Jacek Lewandowski > > > czw., 7 wrz 2023 o 12:58 Brandon Williams napisał(a): > >> +1 >> >> Kind Regards, >> Brando

[DISCUSS] Slab allocation and memory measurements

Hi, While working on integrating the new version of Jamm to Cassandra, I realized that our way to create slabs and how we measure their memory consumption may not be optimal. For the sake of simplicity I will only talk about read-write heap buffers here. Considering that the same principles can b

Re: [VOTE] CEP-8 Datastax Drivers Donation

+1 Le mar. 13 juin 2023 à 16:46, Ekaterina Dimitrova a écrit : > +1 > > On Tue, 13 Jun 2023 at 10:33, Jeff Jirsa wrote: > >> +1 >> >> >> On Tue, Jun 13, 2023 at 7:15 AM Jeremy Hanna >> wrote: >> >>> Calling for a vote on CEP-8 [1]. >>> >>> To clarify the intent, as Benjamin said in the discuss

Re: [DISCUSS] Limiting query results by size (CASSANDRA-11745)

:14 PM, Josh McKenzie >> wrote: >> >> >> Yeah, my bad. I have paging on the brain. Seriously. >> >> I can't think of a use-case in which a LIMIT based on # bytes makes sense >> from a user perspective. >> >> On Mon, Jun 12, 2023, at 1:35 PM

Re: [DISCUSS] Limiting query results by size (CASSANDRA-11745)

either > > > pon., 12 cze 2023 o 11:20 Benedict napisał(a): > > > I agree that this is more suitable as a paging option, and not as a CQL > LIMIT option. > > If it were to be a CQL LIMIT option though, then it should be accurate > regarding result set IMO; there shoul

Re: [DISCUSS] Limiting query results by size (CASSANDRA-11745)

Thanks Jacek for raising that discussion. I do not have in mind a scenario where it could be useful to specify a LIMIT in bytes. The LIMIT clause is usually used when you know how many rows you wish to display or use. Unless somebody has a useful scenario in mind I do not think that there is a nee

Re: [DISCUSS] CEP-8 Drivers Donation - take 2

The idea was to have a single driver sub-project. Even if the code bases are different we believe that it is important to keep the drivers together to retain cohesive API semantics and make sure they have similar functionality and feature support. In this scenario we would need only 3 PMC members f

Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT

+1 Le jeu. 13 avr. 2023 à 08:56, Tommy Stendahl via dev < dev@cassandra.apache.org> a écrit : > +1 (nb) > > -Original Message- > *From*: Brandon Williams > > *Reply-To*: dev@cassandra.apache.org > *To*: dev@cassandra.apache.org > *Subject*: Re: [VOTE] Release Apache Cassandra 4.0.9 - SEC

Re: [VOTE] CEP-26: Unified Compaction Strategy

+1 Le mar. 4 avr. 2023 à 17:17, Andrés de la Peña a écrit : > +1 > > On Tue, 4 Apr 2023 at 15:09, Jeremy Hanna > wrote: > >> +1 nb, will be great to have this in the codebase - it will make nearly >> every table's compaction work more efficiently. The only possible >> exception is tables that

Re: [EXTERNAL] [DISCUSS] Next release date

27;s perspectives on the weight of this >> current decision? We'd probably also have to re-open pandora's box talking >> about the solidity of our API's on trunk as well if we positioned those >> alphas as being stable enough to start prototyping and/or building futu

Re: [EXTERNAL] [DISCUSS] Next release date

gt; To try to address Mick's question, assuming we have Accord depending on > TCM, I'm not sure how closely it can follow TCM in merging. We've been > talking about this In another thread: "[DISCUSS] cep-15-accord, > cep-21-tcm, and trunk", but trying to rebase cep

Re: [EXTERNAL] [DISCUSS] Next release date

27;s box talking about > the solidity of our API's on trunk as well if we positioned those alphas as > being stable enough to start prototyping and/or building future > applications against. > > On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote: > > I am +1 on a 5.0

Re: [EXTERNAL] Re: [DISCUSS] Next release date

> > Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and allowing only CEP-15 and 21 + bug fixes there. Le ven. 24 mars 2023 à 13:55, Paulo Motta a écrit : > > I would like to propose a partial freeze of 5.0 in

Re: [EXTERNAL] Re: [DISCUSS] Next release date

ambov wrote: >> >>> CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy) >>> should both be ready for review by mid-April. >>> >>> Both are around 10k LOC, fairly isolated, and in need of a committer to >>> review. >>> >

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

Hi Doug, Outside of the changes to the Cassandra Sidecar that are mentioned, what the CEP proposes is the donation of a library for Spark integration. It seems to me that this library could be offered as an open source project outside of the Cassandra project itself. If we accept Spark Bulk Analyt

Re: Welcome our next PMC Chair Josh McKenzie

Congratulations!!! Le jeu. 23 mars 2023 à 09:31, Berenguer Blasi a écrit : > Congrats Josh! > On 23/3/23 9:22, Mick Semb Wever wrote: > > It is time to pass the baton on, and on behalf of the Apache Cassandra > Project Management Committee (PMC) I would like to welcome and congratulate > our nex

Re: Should we cut some new releases?

Subject: Re: Should we cut some new releases? > > NetApp Security WARNING: This is an external email. Do not click links or > open attachments unless you recognize the sender and know the content is > safe. > > > > +1 > > On Mon, 13 Mar 2023 at 12:23, Benjamin Lerer ble

Should we cut some new releases?

Hi everybody, Benedict and Jon recently committed the patch for CASSANDRA-18125 which fixes some serious problems at the memtable/flush level. Should we consider cutting some releases that contain this fix?

Re: [EXTERNAL] Re: [DISCUSS] Next release date

Sorry, I realized that when I started the discussion I probably did not frame it enough as I see that it is now going into different directions. The concerns I am seeing are: 1) A too small amount of time between releases is inefficient from a development perspective and from a user perspective. F

Re: [DISCUSSION] Cassandra + Java 17

Hey Ekaterina, Thanks for the update and all the work. > -- we also use setAccessible at numerous places. It is not necessarily a problem as long as we do get an issue with the Modules boundaries and their access. For me it needs to be looked at on a case by case basis. - thoughts around the

[DISCUSS] Next release date

Hi, We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for 4.1 we were only able to release GA in December which impacted how much time we could spend focussing on the next release and the progress that we could do. By consequence, I am wondering if it makes sense for us to branch

Re: Downgradability

> > Can somebody explain to me what is so burdensome, that we seem to be > spending longer debating it than it would take to implement the necessary > changes? I believe that we all agree on the outcome. Everybody wants downgradability. The issue is on the path to get there. As far as I am conce

Re: [DISCUSS] Allow UPDATE on settings virtual table to change running configuration

I have seen issues with some updatable parameters which were missing the volatile keyword. Le mer. 22 févr. 2023 à 11:36, Aleksey Yeshchenko a écrit : > FWIW most of those volatile fields, if not in fact all of them, should NOT > be volatile at all. Someone started the trend and most folks have

Re: Regarding CASSANDRA-14227

Hi Manish, It is unfortunately not an easy bug to fix as it has some significant impact at different levels of the code base. The plan is to have the fix as part of 5.0 which should be released later this year. Le mar. 21 févr. 2023 à 09:48, manish khandelwal < manishkhandelwa...@gmail.com> a écri

Re: Downgradability

> > It seems to me the real issue is nobody noticed this was agreed and/or > forgot and didn’t think about it much. I have some trouble keeping up with all the discussions those days so I might have missed the discussion. The only place I remembered where this subject was mentioned was during the

Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 Le mar. 7 févr. 2023 à 06:21, a écrit : > +1 nb > > On Feb 6, 2023, at 9:05 PM, Ariel Weisberg wrote: > > +1 > > On Mon, Feb 6, 2023, at 11:15 AM, Sam Tunnicliffe wrote: > > Hi everyone, > > I would like to start a vote on this CEP. > > Proposal: > > https://cwiki.apache.org/confluence/displ

Re: Implicitly enabling ALLOW FILTERING on virtual tables

Making ALLOW FILTERING a table option implies giving the right to the person creating the table the ability to change the way the server will behave for that table which might not be something that every C* operator wants. Of course we can allow operators to controle that through the ALLOW FILTERIN

Welcome Patrick McFadin as Cassandra Committer

The PMC members are pleased to announce that Patrick McFadin has accepted the invitation to become committer today. Thanks a lot, Patrick, for everything you have done for this project and its community through the years. Congratulations and welcome! The Apache Cassandra PMC members

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

It seems to me that the question that we need to answer, before Maxim puts more effort into this work, is: what is the future of JMX? I agree that we have never been clear about that decision up to now. At least now we have a reason to clarify that point. I can start a discussion about that if peo

Re: [DISCUSS] Formation of Apache Cassandra Publicity & Marketing Group

Super happy to see this happening. :-) Le sam. 21 janv. 2023 à 00:08, Mick Semb Wever a écrit : > > I'll add the both of you, and anyone else that speaks up. > > To clarify, being a moderator to the mailing list is only about > accepting/rejecting posts being sent from recipients that have not (

Re: [VOTE] CEP-25: Trie-indexed SSTable format

+1 Le lun. 19 déc. 2022 à 16:31, Andrés de la Peña a écrit : > +1 > > On Mon, 19 Dec 2022 at 15:11, Aleksey Yeshchenko > wrote: > >> +1 >> >> On 19 Dec 2022, at 13:42, Ekaterina Dimitrova >> wrote: >> >> +1 >> >> On Mon, 19 Dec 2022 at 8:30, J. D. Jordan >> wrote: >> >>> +1 nb >>> >>> > On De

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

> > Given that we're talking about two one-liners, just changing time units, > what are folks thoughts about skipping rc2 and just re-cutting 4.1.0 (GA) ? It sounds reasonable to me. Le mar. 6 déc. 2022 à 22:36, Aleksey Yeshchenko a écrit : > Sure. > > On 6 Dec 2022, at 18:14, Mick Semb Wever

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

. Admitting that API design can genuinely benefit from user input and > input of others in general, to me, is productive humility - a sign of > maturity. It’s not a reason to be offended. > > > On 6 Dec 2022, at 13:53, Benjamin Lerer wrote: > > > > I am sorry but I still do not

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

I am sorry but I still do not understand what problem we are trying to solve. All examples given so far have been about significant features which we already discuss on this mailing not about minor changes that happen multiple times per week. Is it a trust issue ?

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

why I do not monitor these topics and propose > DISCUSS threads based on activities others are undertaking? This doesn’t > seem like the right approach to me, but if we do not come to some policy > approach here, I will try to schedule some time each quarter to scan for > topic

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

viewed for weeks or months, and finally >>> committed, and still they are questioned shortly after that cycle, and >>> asked to be changed or discussed again. I don't think that an avalanche of >>> DISCUSS threads is going to improve that, since usually the problem

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

+1 Le lun. 5 déc. 2022 à 11:02, Berenguer Blasi a écrit : > +1 > On 5/12/22 10:53, guo Maxwell wrote: > > +1 > > Mick Semb Wever 于2022年12月5日 周一下午5:33写道： > >> >> Proposing the test build of Cassandra 4.1.0 GA for release. >> >> sha1: b807f97b37933fac251020dbd949ee8ef245b158 >> Git: >> https://git

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

Thanks for opening this thread Josh, It seems perfectly normal to me that for important changes or questions we raise some discussion to the mailing list. My understanding of the current proposal implies that for the 4.1 release we should have had to raise over 70 discussion threads. We have a m

  1   2   3   4   5   >