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: [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: [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

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: 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

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: 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: 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: [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: 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

[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: [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

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

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: 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

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: [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: [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: [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] [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] [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 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: [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: [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: [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: [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] 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)

: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: [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

[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] 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] 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] 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

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: [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

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

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

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: 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: 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)

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)

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)

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)

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)

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: 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: 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: 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: [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: [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

-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: 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 (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: > > > > > > >

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 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

[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: [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. >> >>

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

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

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

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

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

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

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

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

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

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

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: 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,

[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

[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

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

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

[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

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, >> >>

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

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] 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: [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] 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

[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] 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

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. >>> >>>

Which approach should we use for exposing metrics through Virtual tables?

Hi, I would like to start working on exposing the metrics through virtual tables in CASSANDRA-14537 We had some long discussion already in CASSANDRA-7622 about which schema to use to expose the metrics, unfortunately in the end I was not tru

Re: Would cqlsh describe command send query to cassandra server ?

Hi, DESCRIBE commands are handled at the driver level not at the server level. The drivers fetch metadata and keep them up to date. When a DESCRIBE command is send, the driver build the output from those metadata. Benjamin On Tue, Aug 7, 2018 at 1:33 PM, 陈仕（shichen）-技术产品中心 wrote: > > Hello, al

Re: NEQ-restriction in select-where clause

It can be done for filtering, otherwise it is really tricky (I am not even sure it can be done to be honest). On Sun, Sep 9, 2018 at 2:11 AM, Dmitry Lazurkin wrote: > Hello. > > Does it make sense to implement != restriction in select-where clause? > Is it possible? > > Thank you. > > PS. I wa

Re: Implicit Casts for Arithmetic Operators

Hi, I would like to try to clarify things a bit to help people to understand the true complexity of the problem. The *float *and *double *types are inexact numeric types. Not only at the operation level. If you insert 676543.21 in a *float* column and then read it, you will realize that the valu

Re: Implicit Casts for Arithmetic Operators

he precision of the result > >> is > >>>>>>>>>>> implementation-defined. > >>>>>>>>>>> " > >>>>>>>>>>> > >>>>>>>>>>> And this makes se

Re: Implicit Casts for Arithmetic Operators

no intention of > producing it (though, of course, I cannot prevent you from producing it) > > For me, the correct approach is to decide where we should be, and then > figure out how to get there. Where we are has no bearing on where we > should be, in my view. > > > > > O

Re: Implicit Casts for Arithmetic Operators

Sorry, following a standard for the sake of following a standard does not make sense to me. On Thu, Nov 22, 2018 at 12:33 PM Benedict Elliott Smith wrote: > Yes. > > > On 22 Nov 2018, at 11:32, Benjamin Lerer > wrote: > > > > Then I would be interested in knowing `

Re: Warn about SASI usage and allow to disable them

+1 on config. +1 on disabling by default On Tue, Jan 15, 2019 at 6:51 AM Jeff Jirsa wrote: > +1 on config > -0 on warning > -0 on disabling by default > > > -- > Jeff Jirsa > > > > On Jan 14, 2019, at 9:22 PM, Taylor Cressy > wrote: > > > > +1 on config. +1 on disabling. > > > > +1 on applying

Re: Stability of MaterializedView in 3.11.x | 4.0

Hi Pankaj, The main issues are described in the link you posted and are some synchronization issues * There's no way to determine if a view is out of sync with the base table. * If you do determine that a view is out of sync, the only way to fix it is to drop and rebuild the view. Even in the hap

Re: [proposal] Introduce AssertJ in test framework

+1 On Tue, Mar 10, 2020 at 6:18 PM Jon Haddad wrote: > I've used assertj in a lot of projects, I prefer it by a wide margin over > using only junit. > > On Tue, Mar 10, 2020 at 9:45 AM David Capwell wrote: > > > +1 from me > > > > In CASSANDRA-15564 I build my own assert chain to make the tests

Re: server side describe

+1 for shipping it after 4.0 On Thu, Apr 2, 2020 at 12:39 AM Jon Haddad wrote: > Most of the work to provide this feature is already done. We need to > generate server side CQL for snapshots already. All we need to do is > expose it via either a "DESCRIBE" CQL command, or I'm equally happy t

Re: server side describe

It seems to me that we need to get better at making decisions for things like that. If we keep on arguing for small things, it will simply be time consuming and painfull for everybody. In this case, the situation seems simple. Part of the group do not agree with the proposal. We just have to accept

Re: server side describe

We have already discussed it for several days and I believe that all the points have been brought to the table. I took the time to read CASSANDRA-14825 this morning to understand the full story. All the discussion has been about using Virtual Tables versus using DESCRIBE. My understanding is that

Re: Keeping test-only changes out of CHANGES.txt

+1 On Thu, Apr 9, 2020 at 9:28 AM Eduard Tudenhoefner < eduard.tudenhoef...@datastax.com> wrote: > updated docs in https://github.com/apache/cassandra/pull/528 > > On Wed, Apr 8, 2020 at 11:39 PM Jordan West wrote: > > > +1 (nb) to the change and +1 (nb) to updating the docs to reflect this. >

Re: server side describe

eed upon. All > further > changes that weren't discussed yet - we can talk over. If it's > something as > trivial as server-side describe that doesn't risk stability but adds a > lot > of value, it may make sense to include. But I woudln't attempt

Re: [VOTE] Release Apache Cassandra 4.0-alpha4

+1 On Tue, Apr 14, 2020 at 5:50 PM Blake Eggleston wrote: > +1 > > > On Apr 14, 2020, at 5:09 AM, e.dimitr...@gmail.com wrote: > > > > I also can’t see them. I think it matters to which interface is the > link. > > > > And +1 from me, thanks! > > > >> On 14 Apr 2020, at 7:53, Erick Ramirez >

Re: server side describe

correct and used virtual > > > tables > > > >> because its what the initial feedback was to do. Robert added a lot > of > > > >> functionality on top of what was there which is what people were > > > starting > > > >> to ask

  1   2   3   4   5   >