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

. Furthermore, there is no means of knowing which action occurred.”That being the case, I think the second option you mention is what keeps consistency with the UPDATEs out of the transaction.Kind regards,BernardoOn Jun 20, 2024, at 1:54 PM, Caleb Rackliffe wrote:We had a bug report a while back from Luis E

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

later, but I suspect that with our > one shot behavior it would get mixed up by multiple attempts to insert if > not exists and then update the same row to achieve upsert. > > Ariel > On Thu, Jun 20, 2024, at 4:54 PM, Caleb Rackliffe wrote: > > We had a bug re

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

+1 on picocli RE the feature branch, I would just maintain the feature branch in your own fork to break out whatever "reviewable units" of code you want. When all the incremental review is done (I have no problem going back and forth), squash everything together, do whatever additional testing you

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

eople can >>>>> sign >>>>> off if they care or not. >>>>> >>>>> I wouldn’t create this thread until you settle on which one you wish >>>>> to move forward with. >>>>> >>>>> Is adding the PicoCLI li

Re: Warn about SASI usage and allow to disable them

+1 to config and disable On Mon, Jan 14, 2019, 1:54 PM Mick Semb Wever > > > The purpose for this thread is discussing whether we want to add this > > warning, the config property and, more controversially, if we want to set > > SASI as disabled by default in trunk. > > > I'm +1 on everything, ex

Re: [VOTE] Release dtest-api 0.0.4

+1 On Fri, Jul 10, 2020 at 9:22 AM Oleksandr Petrov wrote: > Proposing the test build of in-jvm dtest API 0.0.4 for release. > > Repository: > > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.4 > Candidate SHA: > > https://github.com/apache/cassan

Re: [Discussion] Windows support

Hey Yuki, Having just come off CASSANDRA-15861 , where having to take Windows into account certainly complicated things, I'd be in favor of removing Windows support as soon as possible. Another thing that comes to mind is DataStax Desktop: ht

Re: [DISCUSS] CEP-7 Storage Attached Index

+1 On Wed, Aug 26, 2020, 3:45 PM Patrick McFadin wrote: > This is related to the discussion Jordan and I had about the contributor > Zoom call. Instead of open mic for any issue, call it based on a discussion > thread or threads for higher bandwidth discussion. > > I would be happy to schedule o

Re: [DISCUSS] Change style guide to recommend use of @Override

+1 On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang wrote: > +1 > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > > > +1 > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > > > > > Currently our style guide recommends to avoid using @Override and > updates > > > intellij's co

Re: Creating a branch for 5.0 …?

For significant new feature work, the option of working in a public, long-running, trunk-based feature branch is available. If we look at a specific example like CEP-7/SAI, I’m not sure how it would benefit much from a 5.0 branch, at least until it fundamentally depended on other 5.0-targeted wo

Re: [DISCUSS] CEP-7 Storage Attached Index

eds ? > >>>>>> > >>>>>> ~Charles > >>>>>> > >>>>>> On Fri, Aug 28, 2020 at 4:37 PM Patrick McFadin >>> > >>>>>> wrote: > >>>>>>> > >>>>>>> Meeting scheduled. >

Re: [VOTE] Release dtest-api 0.0.5

+1 On Fri, Sep 25, 2020 at 10:08 AM Brandon Williams wrote: > +1 > > On Fri, Sep 25, 2020, 9:45 AM Oleksandr Petrov > > wrote: > > > Proposing the test build of in-jvm dtest API 0.0.5 for release. > > > > Repository: > > > > > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git

Re: 4.0 GA scope: the opt-in approach (CALL TO ACTION)

Opted one issue, CASSANDRA-15821, back into 4.0-rc, as it was meant to complete the documentation for CASSANDRA-15909, which is already resolved. On Wed, Oct 7, 2020 at 2:27 PM David Capwell wrote: > Updated the link to exclude resolved; down to 27 remaining (was 32) > > > https://issues.apache.

Re: Minimal 4.0 COMPACT STORAGE backport

+1 to this, and my immediate concern is the possibility that the patch I'm working on for CASSANDRA-16226 will actually require information about whether a table was *created* with COMPACT STORAGE. On Thu, Oct 22, 2020 at 2:41 PM David Capwel

Pushing CASSANDRA-16262 out of 4.0-rc

Hey everyone, I wanted to have a quick conversation about CASSANDRA-16262 . As I mentioned in the Jira

Re: Pushing CASSANDRA-16262 out of 4.0-rc

e/CASSANDRA-16262> and > > > CASSANDRA-16181 > > > <https://issues.apache.org/jira/browse/CASSANDRA-16181> already highly > > > improve the test coverage on distributed read and write paths. > > > CASSANDRA-16262 sounds like a nice to have but should

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

With concerns around licensing all but resolved, I'd support Pico as our airline replacement. It looks like it would entail the least risky migration, is being actively maintained, will make the development of a number of planned enhancements easier, etc. On Tue, Jul 16, 2024 at 10:40 AM Jeff Jirs

[DISCUSS] Removing support for deterministic table IDs

I'd like to propose removing deterministic table IDs for new *user* tables and views in trunk. With TCM in place, it looks like the reason we added *use_deterministic_table_id*, concurrent table creations, is no longer a concern. Thoughts? Objections?

Re: [DISCUSS] Removing support for deterministic table IDs

; don’t really need the feature anymore. I am fine with deprecating the > feature, but removing would be a breaking change for anyone that had that > config in place, so not a fan of breaking the config interface. > > On Jul 30, 2024, at 1:38 PM, Caleb Rackliffe > wrote: > > I'd

Re: [DISCUSS] Removing support for deterministic table IDs

No intention of touching WITH id in CQL On Tue, Jul 30, 2024 at 4:10 PM Caleb Rackliffe wrote: > To clarify, my plan was to deprecate in Config/JMX and ignore it, not > remove it entirely so it breaks existing YAMLs and JMX clients. > > This should be fine, if I'm reading

Re: [DISCUSS] Removing support for deterministic table IDs

To summarize all this noise I've created, the plan would be... 1.) Leave CQL WITH id intact. 2.) Deprecate and WARN on *use_deterministic_table_id *in 5.0.x. 3.) Ignore and WARN on *use_deterministic_table_id *in 5.1. 4.) Profit On Tue, Jul 30, 2024 at 4:46 PM Caleb Rackliffe wrote:

Re: [DISCUSS] Removing support for deterministic table IDs

Jordan > > On Tue, Jul 30, 2024 at 15:04 Caleb Rackliffe > wrote: > >> To summarize all this noise I've created, the plan would be... >> >> 1.) Leave CQL WITH id intact. >> 2.) Deprecate and WARN on *use_deterministic_table_id *in 5.0.x. >> 3.)

Re: [DISCUSS] Removing support for deterministic table IDs

table is (TableId, Epoch)… and that… is annoying... > > On Jul 30, 2024, at 3:47 PM, Jordan West wrote: > > Understood. Nits aside I have no objection to your plan. > > Jordan > > On Tue, Jul 30, 2024 at 15:42 Caleb Rackliffe > wrote: > >> I think the main moti

Re: [VOTE] Release Apache Cassandra 4.1.6

+1 to proceeding with a simple upgrade note in NEWS On Wed, Jul 31, 2024 at 12:50 PM Josh McKenzie wrote: > Unfortunately, I can not immediately see a good way to provide the > critical bugfix of CASSANDRA-19534 > , affecting all > Cassandra

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

Until we release TCM, it will continue to be possible for nodes to have a divergent view of the ring, and this means operations can still be sent to the wrong nodes. For example, writes may be sent to nodes that do not and never will own that data, and this opens us up to rather devious silent data

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

wrong view > of the cluster for short periods of time while bootstrapping that this > would have prevented. > > Chris > > On Thu, Sep 12, 2024 at 11:16 AM Brandon Williams > wrote: > >> On Thu, Sep 12, 2024 at 11:07 AM Caleb Rackliffe >> wrote: >> > &g

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

ess vs availability, but even that contrast isn't very honest. Being available isn't productive if we're not correct. On Thu, Sep 12, 2024 at 11:46 AM Brandon Williams wrote: > On Thu, Sep 12, 2024 at 11:41 AM Caleb Rackliffe > wrote: > > > > Are you oppose

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

s in 5.0. I’d probably reject by default in 5.0.1.  4.0 / 4.1 - if we treat this like a fix for latent opportunity for data loss (which it implicitly is), I guess? > On Sep 12, 2024, at 9:46 AM, Brandon Williams <dri...@gmail.com> wrote: > > On Thu, Sep 12, 2024 at 11:41 AM Caleb

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

I think I can count at least 4 people on this thread who literally have lost sleep over this. > On Sep 12, 2024, at 1:07 PM, Brandon Williams wrote: > > On Thu, Sep 12, 2024 at 11:52 AM Josh McKenzie > wrote: >> >> More or less surprising than learning that they've been at risk of or >> ac

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

don Williams wrote: > > On Thu, Sep 12, 2024 at 1:13 PM Caleb Rackliffe > wrote: >> >> I think I can count at least 4 people on this thread who literally have lost >> sleep over this. > > Probably good examples of not being the majority though, heh. >

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

If it makes anyone feel better, 2600 of the 3600-lines of this patch are tests (and the rest is minor refactoring of the verb handlers). Anyway, glad to see a ton of participation here. I'll get back into implementation space today, and start dealing with review feedback as it comes in... P.S. I

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

manual operator's involvement. > > How about we also enhance Cassandra to automatically detect and fix the > token ownership mismatch between StorageService and Gossip cache? More > details to this ticket: > https://issues.apache.org/jira/browse/CASSANDRA-18758 > > Jaydee

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

The patches for this issue have gotten a +1 from Mick, and that meets our strict 2 committer rule, but I'm posting them here in case anyone else wants take a look: 4.0: https://github.com/apache/cassandra/pull/3526 4.1: https://github.com/apache/cassandra/pull/3539 5.0: https://github.com/apache/c

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

+1 to making DROP CS experimental (i.e. disabling it by default) w/ a link to the docs explaining the possible side effects The sooner we do that, the more defensible https://issues.apache.org/jira/browse/CASSANDRA-16675 (a proposed solution to the query performance issue mentioned above) becomes.

Re: [DISCUSS] Jira state for second reviewer

+1 > On Jun 30, 2021, at 4:38 PM, Brandon Williams wrote: > > Hello, > > Since our project governance requires two committers, which in some > circumstances may mean two committers need to review, I'd like to add > another state to our jira such that finding tickets that need a second > review

[DISCUSS] The Severity of CASSANDRA-16807

tl;dr At best CASSANDRA-16807 means some queries that shouldn't fail do fail, and at worst, this is a potentially dangerous consistency problem. https://issues.apache.org/jira/browse/CASSANDRA-16807 I'm working on a solution either way, but I want to see if there are any opinions out there on whe

Re: [DISCUSS] The Severity of CASSANDRA-16807

is, since this is nothing new. The > only difference is in how the server is responding to it, and I would > consider an error an improvement over being lied to, if forced to > choose between the two. > > On Fri, Jul 16, 2021 at 2:12 PM Caleb Rackliffe > wrote: > > > > tl;

Re: [VOTE] CEP-14: Paxos Improvements

+1 On Mon, Aug 30, 2021 at 5:12 AM Sam Tunnicliffe wrote: > +1 > > > On 27 Aug 2021, at 20:48, bened...@apache.org wrote: > > > > Hi everyone, I’m proposing this CEP for approval. > > > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements > > Discussio

Re: [DISCUSS] CEP-7 Storage Attached Index

; > time is right. > > > > > > > > On 23/09/2020, 18:45, "Josh McKenzie" wrote: > > > > > > > > talking about that would involve some bits of information > DataStax > > > > might > > > > not be ready to sh

Re: [DISCUSS] CEP-7 Storage Attached Index

voted in. > > I say start the vote and let's get this really valuable developer feature > underway. > > Patrick > > On Tue, Sep 7, 2021 at 10:40 AM Caleb Rackliffe > wrote: > > > So this thread stalled almost a year ago. (Wow, time flies when you're >

Re: [DISCUSS] Mentoring newcomers

You have my bow. On Fri, Nov 12, 2021 at 11:05 AM Benjamin Lerer wrote: > Hi everybody > > As discussed in the *Creating a new slack channel for newcomers* thead, a > solution to help newcomers engage with the project would be to provide a > list of mentors that newcomers can contact when they f

Re: Implementing a secondary index

Hi Claude, In code space, the best place to start would be the secondary index API and the manager that maintains the indexes on a per-table basis: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/Index.java https://github.com/apache/cassandra/blob/trunk/src/java

Re: [DISCUSS] Nested YAML configs for new features

If it's nested, "track_warnings" would still work if you're grepping around vim or less. I'd have to concede the point about grep output, although there are tools like https://github.com/kislyuk/yq that could probably be bent to do what you want. On Fri, Nov 19, 2021 at 1:08 PM Stefan Miklosovic

Re: [DISCUSS] Nested YAML configs for new features

currently configured. On Fri, Nov 19, 2021 at 3:08 PM Caleb Rackliffe wrote: > If it's nested, "track_warnings" would still work if you're grepping > around vim or less. > > I'd have to concede the point about grep output, although there are tools > like

Re: [VOTE] Formalizing our CI process

+1 w/ Joey's amendment On Wed, Jan 12, 2022 at 11:04 AM Joshua McKenzie wrote: > I'd say an amendment with a directional poll would be fine. I don't think > this is controversial. > > That's me taking "the spirit of the law" rather than the letter though. > I'm good either way. > > ~Josh > > On

Re: [DISCUSS] Next release cut

+1 On Mon, Jan 3, 2022 at 1:21 PM Brandon Williams wrote: > +1 to 4.1 in May. > > On Tue, Dec 14, 2021, 6:46 AM Mick Semb Wever wrote: > >> > We cut 4.0 in May and released it in July. It is difficult to plan for a >> release date so we should probably agree on the cut date. One year after >> 4

Re: [DISCUSS] Patching, versioning, and LTS releases

Looks good on a quick reading. The question around whether to merge with the "Release Lifecycle" wiki article doesn't seem super ugent. That article seems to be scoped to how individual releases evolve through time, while this one deals with how we deal with the set of releases active at any given

Re: [VOTE] release cassandra-harry 0.0.1

+1 On Mon, Feb 7, 2022 at 8:44 AM Alex Petrov wrote: > Proposing the test build of cassandra-harry 0.0.1 for release, to start > using it in Cassandra tree. > > Repository: > > https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.1 > > Candidate SHA: > > https://g

Re: [DISCUSS] CEP-7 Storage Attached Index

Regarding SASI deprecation and removal, I think I'm on the same page as Henrik. The grand glorious future involves getting to feature parity with and then completely replacing legacy 2i and SASI, but the CEP need not specify a hard timeline for this. With respect to OR support, I'm actually comple

Re: [DISCUSS] CEP-7 Storage Attached Index

Just finished reading the latest version of the CEP. Here are my thoughts: - We've already talked about OR queries, so I won't rehash that, but tokenization support seems like it might be another one of those places where we can cut scope if we want to get V1 out the door. It shouldn't be that har

Re: [DISCUSS] CEP-7 Storage Attached Index

SAI framework and plumbing. > > MikeA > >> On 11 Feb 2022, at 18:47, Caleb Rackliffe wrote: >> >> Just finished reading the latest version of the CEP. Here are my thoughts: >> >> - We've already talked about OR queries, so I won't rehash that, b

Re: [DISCUSS] CEP-7 Storage Attached Index

able support are now covered in the Addenda. > > MikeA > > On 14 Feb 2022, at 15:35, Caleb Rackliffe > wrote: > > Agreed there’s no reason to pull it out. I was just wondering what state > it was in, given I didn’t see it mentioned in the CEP. > > On Feb 14, 2022,

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

Hey everyone, There has already been some Slack discussion around this, but for anyone who doesn't follow that closely, I'd like to lobby more widely for my proposal in CASSANDRA-17292

[VOTE] CEP-7: Storage Attached Index

Hi everyone, I'd like to call a vote to approve CEP-7. Proposal: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-7%3A+Storage+Attached+Index Discussion: https://lists.apache.org/thread/hh67k3t86m7299qkt61gmzb4h96bl90w The vote will be open for 72 hours. Votes by committers are conside

Re: [VOTE] CEP-7: Storage Attached Index

;> wrote: > >> > >> +1 nb. Thanks Caleb, Mike, Jason, and everyone involved with > >> the effort. > >> > >>> On Feb 17, 2022, at 4:23 PM, Caleb Rackliffe > >>> mailto:calebrackli...@gmail.com>> >

Re: [VOTE] CEP-7: Storage Attached Index

The vote passes, with 4 binding +1 votes, 4 non-binding +1 votes, and zero binding vetos. > On Feb 21, 2022, at 11:11 AM, Caleb Rackliffe > wrote: > >  > Given this spanned the weekend, I'll leave the vote open for today... > >> On Fri, Feb 18, 2022 at 10:27

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

om > changing the config format, could be added before and support any format > - the bare information is already available in system_views.settings > - could be combined with #1 or #3 to support the format translation > cons: ? > > > My favourite would be #3 + #4, while

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

on element is added to the YAML, then it is not necessary to >>>> change the filename, thus we could end up with #3. The value of the >>>> version element could default to 1 in the first phase, which does not need >>>> any change for legacy format configurat

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

ANDRA-17292 Move cassandra.yaml toward a > nested structure around major database concepts > > +1 to a non-incremental approach as well. > > On 23/2/22 1:27, Caleb Rackliffe wrote: > > @Patrick I’m absolutely intending for this to be a 5.0 concern. The only > reason why it woul

Re: [DISCUSSION] Cassandra-17515 - course of action

I'm for making >= 0 valid in both the setters and on startup. In the setters, I'm fine with either translating negative values to the default calculated value based on heap size or simply rejecting negative values. If we really want to override that value, we had better have a really good idea of w

Re: Call for Volunteers - Build Lead

I'll take the week of 4/11-15. On Mon, Apr 4, 2022 at 5:33 AM Mick Semb Wever wrote: > > We went last week without a Build Lead. We have one for this week, but we > are looking for volunteers for next week and the weeks ahead. > > This is an important activity to get us to green - once we are gr

Re: Call for Volunteers - Build Lead

ew new test flake Jiras. On Thu, Apr 7, 2022 at 11:33 AM Caleb Rackliffe wrote: > I'll take the week of 4/11-15. > > On Mon, Apr 4, 2022 at 5:33 AM Mick Semb Wever wrote: > >> >> We went last week without a Build Lead. We have one for this week, but we >> ar

Re: [DISCUSSION] Handling precision when reporting stream_throughput_outbound_megabits_per_sec and inter_dc_stream_throughput_outbound_megabits_per_sec

My $0.02... Options from best to worst: 1.) Use double when possible (chopping off non-sig-digs after the decimal if you want) 2.) Complain loudly that we would have to round and error out. --line of acceptable behavior 100.) Round silently ;) On Mon, Jul

Re: CEP-15 multi key transaction syntax

Avi brought up an interesting point around NULLness checking in CASSANDRA-17762 ... In SQL, any comparison with NULL is NULL, which is interpreted as FALSE in > a condition. To test for NULLness, you use IS NULL or IS NOT NULL. But LWT > uses

Hint transfer during decommission

Hey friends, I'm looking for some feedback on whether what's been proposed in CASSANDRA-17808 is reasonable. To summarize... 1.) We continue to transfer hints by default during decommission, but at a higher rate. We could, for instance, stop

Re: CEP-15 multi key transaction syntax

s anyone have any other alternatives? Preference for one of the above options? Thanks! On Fri, Jul 22, 2022 at 11:21 AM Caleb Rackliffe wrote: > Avi brought up an interesting point around NULLness checking in > CASSANDRA-17762 <https://issues.apache.org/jira/browse/CASSANDRA-17762>

Re: CEP-15 multi key transaction syntax

WHERE k=1 AND c=0; SELECT x, row2_v IF x IS NULL AND row2_v = 3 THEN INSERT INTO ks.tbl (k, c, v) VALUES (0, 0, 1); END IF COMMIT TRANSACTION On Thu, Aug 11, 2022 at 12:12 PM Caleb Rackliffe wrote: > Hello again everyone! > > I've been working on a prototype > <https

Re: CEP-15 multi key transaction syntax

ULL AND row2.v = 3 THEN INSERT INTO ks.tbl (k, c, v) VALUES (0, 0, 1); END IF COMMIT TRANSACTION On Thu, Aug 11, 2022 at 12:55 PM Caleb Rackliffe wrote: > via Benedict, here is a 4th option: > > 4.) Similar to #2, but don't rely on the key element being NULL. > > If the

Re: CEP-15 multi key transaction syntax

T EXISTS when creating new tables. IS NULL/IS NOT NULL is >> used in materialized views similarly to proposals 2,4 and 5. >> >> CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] [keyspace_name.]view_name >> AS SELECT [ (column_list) ] >> FROM [keyspace_name.]table_name >>

Re: CEP-15 multi key transaction syntax

Ha, apologies to Avi ;) On Mon, Aug 15, 2022 at 2:01 PM Benedict Elliott Smith wrote: >  > > I like Benedict's tuple deconstruction idea > > > For posterity, this was Avi’s idea! > > On 15 Aug 2022, at 18:59, Caleb Rackliffe > wrote: > > Monday Morning

Re: CEP-15 multi key transaction syntax

lowing) SELECT on LET > > Patrick > > On Mon, Aug 15, 2022 at 11:01 AM Caleb Rackliffe > wrote: > >> Monday Morning Caleb has digested, and here's where I am... >> >> 1.) I have no problem w/ having SELECT on the RHS of a LET assignment, >> and to be honest,

Re: [DISCUSS] Removing support for java 8

+1 on removing 8 for trunk On Tue, Aug 30, 2022 at 2:42 PM Jon Haddad wrote: > +1 to removal of 8 in trunk. > > On 2022/08/29 20:09:55 Blake Eggleston wrote: > > Hi all, I wanted to propose removing jdk8 support for 4.1. Active > support ended back in March of this year, and I believe the commun

Re: [DISCUSS] LWT UPDATE semantics with + and - when null

Also +1 on the SQL behavior here. I was uneasy w/ coercing to "" / 0 / 1 (depending on the type) in our previous discussion, but for some reason didn't bring up the SQL analog :-| On Tue, Aug 30, 2022 at 5:38 PM Benedict wrote: > I’m a bit torn here, as consistency with counters is important. Bu

Re: CEP-15 multi key transaction syntax

; implementation. I'm going to walk through my reasoning for your >>> >>>> proposals wrt trying to explain this to somebody new. >>> >>>> >>> >>>> Looking at all the options, the first thing that comes up for me is >>>

Re: Shall 4.2 become 5.0 ?

It's obviously still in progress, but CASSANDRA-16052 may introduce some breaking changes to the 2i API. On Mon, Sep 26, 2022 at 12:45 PM Josh McKenzie wrote: > qualifies to me as “this release is not backwards compatible with 4.1”. > > I'm

Re: Shall 4.2 become 5.0 ?

Mick, Ignore me. I misread your original post. On Mon, Sep 26, 2022 at 2:01 PM Ekaterina Dimitrova wrote: > We agreed long ago to drop the JavaScript UDFs, they were already > deprecated in CASSANDRA-17280 > That was decided around Nashorn and JDK17 and there is ticket > CASSANDRA-17281 to co

Re: [VOTE] Release Apache Cassandra 4.1-beta1

+1 Also, FWIW, https://issues.apache.org/jira/browse/CASSANDRA-17927 has been resolved. On Mon, Oct 3, 2022 at 9:37 AM Ekaterina Dimitrova wrote: > As long as those two are checked to be test issues and we agree to fix > them before next release, I am also +1 > > On Mon, 3 Oct 2022 at 9:42, Jos

Re: Naming conventions for CQL native functions

+100 on snake case for built-in functions given I think MySQL and Postgres use that convention as well. ex. https://www.postgresql.org/docs/9.2/functions-string.html On Thu, Nov 10, 2022 at 7:51 AM Brandon Williams wrote: > I too meant snake case and need coffee. > > On Thu, Nov 10, 2022, 7:26

[DISCUSS] 5.0 Upgrades and CASSANDRA-19989

Hey folks, I think we should probably not recommend 5.0 upgrades until CASSANDRA-19989 is released. It could cause a significant amount of unnecessary read-repair activity on TTL'd data while an upgrade is in progress.

Re: [DISCUSS] 5.0 Upgrades and CASSANDRA-19989

Just to close the loop, this is committed to 5.0 and trunk. On Wed, Oct 9, 2024 at 3:07 PM Caleb Rackliffe wrote: > Hey folks, > > I think we should probably not recommend 5.0 upgrades until > CASSANDRA-19989 <https://issues.apache.org/jira/browse/CASSANDRA-19989> > is rel

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

Josh's example of "good" usage seems defensible, because the declared type is already obfuscated to Collection anyway, and my eyeballs are going to skip to the right anyway to see the instantiated type. I'm +0 on prohibiting it in non-test code, and -1 on prohibiting it in tests. On Tue, Oct 29, 2

Re: CEP-15: Accord status

There is also a Jira to track pre-merge tasks here: https://issues.apache.org/jira/browse/CASSANDRA-18196 > On Sep 20, 2024, at 4:09 PM, Josh McKenzie wrote: > >  >> >> This presents an opportune moment for those interested to review the code. >> ... >> +88,341 −7,341 >> 1003 Files changed >

[DISCUSS] Secondary Indexes and Single-Partition Reads

Hello fellow secondary index enjoyers! If you're familiar with index queries, you probably know that they are treated as range reads no matter what. This is true even if the user query restricts results to a single partition. This means that they bypass the digest read process that normal single-p

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

erty that switches this behavior. On Tue, Oct 1, 2024 at 12:43 PM Jeff Jirsa wrote: > > > > On Oct 1, 2024, at 10:28 AM, Caleb Rackliffe > wrote: > > > > Hello fellow secondary index enjoyers! > > > > If you're familiar with index queries, you proba

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

I think this is a good change over all. > > On Oct 1, 2024 at 1:51:10 PM, Jon Haddad wrote: > >> This seems like it's strictly a win. Doesn't sound to me like a flag is >> needed. >> >> On Tue, Oct 1, 2024 at 2:44 PM Caleb Rackliffe >> wrote: >

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

Alrighty, with what looks like a fair amount of support, I'll declare CASSANDRA-19968 <https://issues.apache.org/jira/browse/CASSANDRA-19968> ready for some preliminary review. On Tue, Oct 1, 2024 at 2:41 PM Caleb Rackliffe wrote: > We did add CASSANDRA-18940 > <https://is

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

Tue, Oct 1, 2024 at 9:23 PM Jon Haddad wrote: > This also seems like an optimization. Why not go in 5.0? > > > On Tue, Oct 1, 2024 at 10:14 PM Jordan West wrote: > >> Agreed this would absolutely be a win. Dont see need for a flag either. >> >> On Tue,

[DISCUSS] Removing v30 and v3X from trunk in-JVM upgrade tests

The subject line probably says it all, but just to confirm, we won't be supporting 3.11 -> 5.1/trunk upgrades, correct? If that's correct, I'm going to go ahead and remove v30 and v3X from UpgradeTestBase and deal with the downstream changes in whatever way seems reasonable (without actually remov

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

I think we can handle manual index selection controls independently of the larger problem of query optimization. Once I have time to get to know CEP-39 and the DS approach a little better, I can open another thread here to start talking about those in the context of the problems we need to solve.

Re: [DISCUSS] Default Selection of 2i

A little hesitant of just changing it outright in a patch release. > > > > On Feb 6, 2025 at 1:10:28 PM, Caleb Rackliffe > wrote: > >> Hey everyone! >> >> I'll keep this short. SASI and later SAI, in lieu of anything resembling >> a query planner, hav

[DISCUSS] Default Selection of 2i

Hey everyone! I'll keep this short. SASI and later SAI, in lieu of anything resembling a query planner, have always just greedily returned a min long from Index#getEstimatedResultRows(), thereby stealing the right to be used to execute the query even when a legacy 2i is present on the relevant col

Re: [DISCUSS] Default Selection of 2i

fine.- Scott—MobileOn Feb 6, 2025, at 11:42 AM, Caleb Rackliffe <calebrackli...@gmail.com> wrote:System property works for me, even if I have to leave the default alone in 5.0.xOn Thu, Feb 6, 2025 at 1:34 PM Jeremiah Jordan <jeremiah.jor...@gmail.com> wrote: Rather than changing th

Re: Meaningless emptiness and filtering

The case where allowsEmpty == true AND is meaningless == true is especially confusing. If I could design this from scratch, I would reject writes and filtering on EMPTY values for int and the other types where meaningless == true. (In other words, if we allow EMPTY, it is meaningful and queryable.

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

deprecate 2i and recommend users switch to either global secondary indexes or SAI. Until then, I cannot see a good argument for it if we want to be considered a stable and mature product.On 10 Dec 2024, at 09:28, Caleb Rackliffe wrote:> I’m not convinced SAI has demonstrated a practical o

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I misspoke earlier about the feature gap. SAI supports queries legacy 2i does not, like numeric range queries.On Dec 10, 2024, at 9:29 AM, Caleb Rackliffe wrote:I think my point here is that the hidden table 2i implementation has known correctness/availability/operational/resource usage issues

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> I’m not convinced SAI has demonstrated a practical or theoretical capability to fully replace secondary indexes anyway. So it would be very premature to mark them deprecated. > If 2i indexes are to be marked as deprecated and SAI is beta, then what is actually the index implementation we stand b

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Let's say we went with the preview -> beta -> GA option. Does something like SASI stay in "experimental" while MV, transient replication, etc. move to "preview"? On Tue, Dec 10, 2024 at 11:30 AM Jeremiah Jordan wrote: > I agree with Aleksey and Patrick. We should define terminology and then > s

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

ca to be > replaced). This isn’t a “remove the feature” level bug though, given my > current understanding of it. If anything, it would be much more work than > just fixing the bug. > > If there’s a longer litany of breaking behaviours, let’s enumerate them > and consider marking the

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

+1 to Josh's refinement of JD's proposal On Tue, Dec 10, 2024 at 11:42 AM Josh McKenzie wrote: > +1 to this classification with one addition. I think we need to augment > this with formalization on what we do with features we don't recommend > people use (i.e. MV in their current incarnation). F

Re: [DISCUSS] 5.1 should be 6.0

I don't care what we call it as long as 4.1 -> 5.1/6.0 upgrades are possible. On Tue, Dec 10, 2024 at 1:28 PM David Capwell wrote: > Given our version support… if we do make this change does this imply users > must do the following to get to 6.0? > > 4.x upgrade to 5.0 > 5.0 upgrade to 6.0 > > S

<    1   2   3   >