Re: [DISCUSS] Adding support for BETWEEN operator
Range restrictions (>, >=, =<, < and BETWEEN) do not work on UPDATEs. They do work on DELETE because under the hood C* they get translated into range tombstones. Le mar. 14 mai 2024 à 02:44, David Capwell a écrit : > I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this work. > > On May 13, 2024, at 7:40 AM, Patrick McFadin wrote: > > This is a great feature addition to CQL! I get asked about it from time to > time but then people figure out a workaround. It will be great to just have > it available. > > And right on Simon! I think 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, >> >> 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 senior project >> contributing to Apache Cassandra. This patch is his first contribution for >> his senior project (his second feature contribution to Apache Cassandra). >> >> >> >
Re: [RESULT] [VOTE] Release Apache Cassandra 3.0.30
Hi all, As I have mentioned on many other projects mailing lists, that also had the habit of counting "implicit votes" ... at the ASF there is no such thing as an "implicit vote" on a release. Feel free to add an "this email also counts as my +1" to the initial VOTE email or even better, cast an explicit vote. I personally have voted on many of my own RCs with -1 as I found things when executing the release checks after staging the RC. Chris On 2024/05/09 05:36:26 Justin Mclean wrote: > Hi, > > Correct as it didn't contain a +1 in it. > > Justin >
Re: [DISCUSS] Adding support for BETWEEN operator
Is there a technical limitation that would prevent a range write that functions the same way as a 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 the hood C* they get translated into range > tombstones. > > Le mar. 14 mai 2024 à 02:44, David Capwell a écrit : > >> I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this >> work. >> >> On May 13, 2024, at 7:40 AM, Patrick McFadin wrote: >> >> This is a great feature addition to CQL! I get asked about it from time >> to time but then people figure out a workaround. It will be great to just >> have it available. >> >> And right on Simon! I think 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, >>> >>> 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 senior project >>> contributing to Apache Cassandra. This patch is his first contribution for >>> his senior project (his second feature contribution to Apache Cassandra). >>> >>> >>> >>
Community over Code EU 2024: The countdown has started!
[Note: You're receiving this email because you are subscribed to one or more project dev@ mailing lists at the Apache Software Foundation.] We are very close to Community Over Code EU -- check out the amazing program and the special discounts that we have for you. Special discounts You still have the opportunity to secure your ticket for Community Over Code EU. Explore the various options available, including the regular pass, the committer and groups pass, and now introducing the one-day pass tailored for locals in Bratislava. We also have a special discount for you to attend both Community Over Code and Berlin Buzzwords from June 9th to 11th. Visit our website to find out more about this opportunity and contact te...@sg.com.mx to get the discount code. Take advantage of the discounts and register now! https://eu.communityovercode.org/tickets/ Check out the full program! This year Community Over Code Europe will bring to you three days of keynotes and sessions that cover topics of interest for ASF projects and the greater open source ecosystem including data engineering, performance engineering, search, Internet of Things (IoT) as well as sessions with tips and lessons learned on building a healthy open source community. Check out the program: https://eu.communityovercode.org/program/ Keynote speaker highlights for Community Over Code Europe include: * Dirk-Willem Van Gulik, VP of Public Policy at the Apache Software Foundation, will discuss the Cyber Resiliency Act and its impact on open source (All your code belongs to Policy Makers, Politicians, and the Law). * Dr. Sherae Daniel will share the results of her study on the impact of self-promotion for open source software developers (To Toot or not to Toot, that is the question). * Asim Hussain, Executive Director of the Green Software Foundation will present a framework they have developed for quantifying the environmental impact of software (Doing for Sustainability what Open Source did for Software). * Ruth Ikegah will discuss the growth of the open source movement in Africa (From Local Roots to Global Impact: Building an Inclusive Open Source Community in Africa) * A discussion panel on EU policies and regulations affecting specialists working in Open Source Program Offices Additional activities * Poster sessions: We invite you to stop by our poster area and see if the ideas presented ignite a conversation within your team. * BOF time: Don't miss the opportunity to discuss in person with your open source colleagues on your shared interests. * Participants reception: At the end of the first day, we will have a reception at the event venue. All participants are welcome to attend! * Spontaneous talks: There is a dedicated room and social space for having spontaneous talks and sessions. Get ready to share with your peers. * Lighting talks: At the end of the event we will have the awaited Lighting talks, where every participant is welcome to share and enlighten us. Please remember: If you haven't applied for the visa, we will provide the necessary letter for the process. In the unfortunate case of a visa rejection, your ticket will be reimbursed. See you in Bratislava, Community Over Code EU Team
Re: [DISCUSS] Adding support for BETWEEN operator
It should be like range tombstones ... in much worse ;-). A tombstone is a simple marker (deleted). An update can be far more complex. Le mar. 14 mai 2024 à 15:52, Jon Haddad a écrit : > Is there a technical limitation that would prevent a range write that > functions the same way as a 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 the hood C* they get translated into >> range tombstones. >> >> Le mar. 14 mai 2024 à 02:44, David Capwell a écrit : >> >>> I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this >>> work. >>> >>> On May 13, 2024, at 7:40 AM, Patrick McFadin wrote: >>> >>> This is a great feature addition to CQL! I get asked about it from time >>> to time but then people figure out a workaround. It will be great to just >>> have it available. >>> >>> And right on Simon! I think 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, 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 senior project contributing to Apache Cassandra. This patch is his first contribution for his senior project (his second feature contribution to Apache Cassandra). >>>
Re: [DISCUSS] Adding support for BETWEEN operator
Ranged update sounds like a disaster for compaction and read performance. Imagine compacting or reading some SSTables in which a large number of overlapping but non-identical ranges were updated with different 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 with them at read and compaction time doesn't suffer in the long term. On 14/05/2024 16:59, Benjamin Lerer wrote: It should be like range tombstones ... in much worse ;-). A tombstone is a simple marker (deleted). An update can be far more complex. Le mar. 14 mai 2024 à 15:52, Jon Haddad a écrit : Is there a technical limitation that would prevent a range write that functions the same way as a 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 the hood C* they get translated into range tombstones. Le mar. 14 mai 2024 à 02:44, David Capwell a écrit : I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this work. On May 13, 2024, at 7:40 AM, Patrick McFadin wrote: This is a great feature addition to CQL! I get asked about it from time to time but then people figure out a workaround. It will be great to just have it available. And right on Simon! I think 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, 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 senior project contributing to Apache Cassandra. This patch is his first contribution for his senior project (his second feature contribution to Apache Cassandra).
Re: Is there appetite to maintain the gocql driver (in the drivers subproject) ?
Ok, so we're got confidence now on how to approach this, confirmation from the project's maintainers supporting it, and interest from a handful of people interested in maintaining and contributing to the project. The proposed plan forward is… We will go through a round of collecting CLAs along with agreements to donate work to ASF from all gocql authors, over email and LinkedIn searches and messages. We will also open a github issue on the gocql project describing the steps involved and mentioning all the authors. A response on the GH issue from everyone agreeing to the donation is the best single place to collect the responses from everyone, but we'll accept and work with whatever/however we get them. These authors will also need to sign this ICLA and submit it to the ASF. After a four week grace period we will move ahead with the IP donation to ASF, and make a list of all work (files) that we don't have CLAs for. Such work may remain with headers honouring their past MIT license and authors. When the work is accepted and brought into the Cassandra Driver subproject we will be looking to add committers to the subproject. These may or may not be people who have expressed interest in further contributing to the codebase, but rather people we trust regardless when/if they come back to contribute. Does anyone call out the need for a new CEP for bringing the gocql into the Driver's subproject ? My suggestion is that this falls under CEP-8, even if it is not DataStax donating this particular codebase, the process is largely the same and it is the Drivers subproject receiving it. On Mon, 15 Apr 2024 at 12:31, Mick Semb Wever wrote: > > > > We can open an issue with LEGAL to see what they say at least? >>> >> >> >> I will raise a LEGAL ticket. >> >> My question here is whether we have to go through the process of >> best-efforts to get approval to donate (transfer copyright), or whether we >> can honour the copyright on the prior work and move forward ( by >> referencing it in our NOTICE.txt, as per >> https://infra.apache.org/licensing-howto.html ) >> > > > https://issues.apache.org/jira/browse/LEGAL-674 >
Re: [DISCUSS] Adding support for BETWEEN operator
Personally, I don't think that something being scary at first glance is a good reason not to explore an idea. The scenario you've described here is tricky but I'm not expecting it to be any worse than say, SAI, which (the last I checked) has O(N) complexity on returning result sets with regard to rows returned. We've also merged in Vector search which has O(N) overhead with the number of SSTables. We're still fundamentally looking at, in most cases, a limited number of SSTables and some merging of values. Write updates are essentially a timestamped mask, potentially overlapping, and I suspect potentially resolvable during compaction by propagating the values. They could be eliminated or narrowed based on how they've propagated by using the timestamp metadata on the SSTable. It would be a lot more constructive to apply our brains towards solving an interesting problem than pointing out all its potential flaws based on gut feelings. We haven't even moved this past an idea. I think it would solve a massive problem for a lot of people and is 100% worth considering. Thanks Patrick and David for raising this. Jon On Tue, May 14, 2024 at 9:48 AM Bowen Song via dev wrote: > Ranged update sounds like a disaster for compaction and read performance. > > Imagine compacting or reading some SSTables in which a large number of > overlapping but non-identical ranges were updated with different 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 with them at read and compaction time > doesn't suffer in the long term. > > On 14/05/2024 16:59, Benjamin Lerer wrote: > > It should be like range tombstones ... in much worse ;-). A tombstone is a > simple marker (deleted). An update can be far more complex. > > Le mar. 14 mai 2024 à 15:52, Jon Haddad a écrit : > >> Is there a technical limitation that would prevent a range write that >> functions the same way as a 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 the hood C* they get translated into >>> range tombstones. >>> >>> Le mar. 14 mai 2024 à 02:44, David Capwell a >>> écrit : >>> I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this work. On May 13, 2024, at 7:40 AM, Patrick McFadin wrote: This is a great feature addition to CQL! I get asked about it from time to time but then people figure out a workaround. It will be great to just have it available. And right on Simon! I think 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, > > 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 senior project > contributing to Apache Cassandra. This patch is his first contribution for > his senior project (his second feature contribution to Apache Cassandra). > > >
Re: [DISCUSS] Adding support for BETWEEN operator
> > It would be a lot more constructive to apply our brains towards solving an > interesting problem than pointing out all its potential flaws based on gut > feelings. It is not simply a gut feeling, Jon. This change impacts read, write, indexing, storage, compaction, repair... The risk and cost associated with it are pretty significant and I am not convinced at this point of its benefit. Le mar. 14 mai 2024 à 19:05, Jon Haddad a écrit : > Personally, I don't think that something being scary at first glance is a > good reason not to explore an idea. The scenario you've described here is > tricky but I'm not expecting it to be any worse than say, SAI, which (the > last I checked) has O(N) complexity on returning result sets with regard to > rows returned. We've also merged in Vector search which has O(N) overhead > with the number of SSTables. We're still fundamentally looking at, in most > cases, a limited number of SSTables and some merging of values. > > Write updates are essentially a timestamped mask, potentially overlapping, > and I suspect potentially resolvable during compaction by propagating the > values. They could be eliminated or narrowed based on how they've > propagated by using the timestamp metadata on the SSTable. > > It would be a lot more constructive to apply our brains towards solving an > interesting problem than pointing out all its potential flaws based on gut > feelings. We haven't even moved this past an idea. > > I think it would solve a massive problem for a lot of people and is 100% > worth considering. Thanks Patrick and David for raising this. > > Jon > > > > On Tue, May 14, 2024 at 9:48 AM Bowen Song via dev < > dev@cassandra.apache.org> wrote: > >> Ranged update sounds like a disaster for compaction and read performance. >> >> Imagine compacting or reading some SSTables in which a large number of >> overlapping but non-identical ranges were updated with different 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 with them at read and compaction time >> doesn't suffer in the long term. >> >> On 14/05/2024 16:59, Benjamin Lerer wrote: >> >> It should be like range tombstones ... in much worse ;-). A tombstone is >> a simple marker (deleted). An update can be far more complex. >> >> Le mar. 14 mai 2024 à 15:52, Jon Haddad a écrit : >> >>> Is there a technical limitation that would prevent a range write that >>> functions the same way as a 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 the hood C* they get translated into range tombstones. Le mar. 14 mai 2024 à 02:44, David Capwell a écrit : > I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this > work. > > On May 13, 2024, at 7:40 AM, Patrick McFadin > wrote: > > This is a great feature addition to CQL! I get asked about it from > time to time but then people figure out a workaround. It will be great to > just have it available. > > And right on Simon! I think 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, >> >> 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 senior project >> contributing to Apache Cassandra. This patch is his first contribution >> for >> his senior project (his second feature contribution to Apache Cassandra). >> >> >> >
Re: Is there appetite to maintain the gocql driver (in the drivers subproject) ?
Does anyone call out the need for a new CEP for bringing the gocql into the Driver's subproject ? > My suggestion is that this falls under CEP-8, even if it is not DataStax > donating this particular codebase, the process is largely the same and it is > the Drivers subproject receiving it. +1 to future driver donations falling under CEP-8 On Tue, May 14, 2024, at 1:03 PM, Mick Semb Wever wrote: > > Ok, so we're got confidence now on how to approach this, confirmation from > the project's maintainers supporting it, and interest from a handful of > people interested in maintaining and contributing to the project. > > The proposed plan forward is… > > We will go through a round of collecting CLAs along with agreements to donate > work to ASF from all gocql authors, over email and LinkedIn searches and > messages. We will also open a github issue on the gocql project describing > the steps involved and mentioning all the authors. A response on the GH > issue from everyone agreeing to the donation is the best single place to > collect the responses from everyone, but we'll accept and work with > whatever/however we get them. These authors will also need to sign this > ICLA and submit it to the ASF. > > After a four week grace period we will move ahead with the IP donation to > ASF, and make a list of all work (files) that we don't have CLAs for. Such > work may remain with headers honouring their past MIT license and authors. > When the work is accepted and brought into the Cassandra Driver subproject we > will be looking to add committers to the subproject. These may or may not be > people who have expressed interest in further contributing to the codebase, > but rather people we trust regardless when/if they come back to contribute. > > Does anyone call out the need for a new CEP for bringing the gocql into the > Driver's subproject ? > My suggestion is that this falls under CEP-8, even if it is not DataStax > donating this particular codebase, the process is largely the same and it is > the Drivers subproject receiving it. > > > > On Mon, 15 Apr 2024 at 12:31, Mick Semb Wever wrote: >> >> >> We can open an issue with LEGAL to see what they say at least? >>> >>> >>> I will raise a LEGAL ticket. >>> >>> My question here is whether we have to go through the process of >>> best-efforts to get approval to donate (transfer copyright), or whether we >>> can honour the copyright on the prior work and move forward ( by >>> referencing it in our NOTICE.txt, as per >>> https://infra.apache.org/licensing-howto.html ) >> >> >> https://issues.apache.org/jira/browse/LEGAL-674
Re: Is there appetite to maintain the gocql driver (in the drivers subproject) ?
On Tue, May 14, 2024 at 10:05 AM Mick Semb Wever wrote: > > Ok, so we're got confidence now on how to approach this, confirmation from > the project's maintainers supporting it, and interest from a handful of > people interested in maintaining and contributing to the project. > Did you talk to the current maintainers off list or did I miss some thread where the maintainers indicated their support in maintaining this project?
