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,

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

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

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

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

Re: [DISCUSS] CEP-7 Storage Attached Index

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

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

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

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:

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

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 >

Re: Pushing CASSANDRA-16262 out of 4.0-rc

> > > 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 probably not > block > &

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

Re: [DISCUSS] CEP-7 Storage Attached Index

> 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 > > trying to re

Re: [DISCUSS] CEP-7 Storage Attached Index

s 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 share? > > >

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

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

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

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 https://github.com/kisly

[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

Re: [DISCUSS] The Severity of CASSANDRA-16807

his, 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;dr At

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

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

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

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 configuration. New conf

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,

[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

[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

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

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

2 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 would have any

Re: [DISCUSS] CEP-7 Storage Attached Index

ork 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, but >> toke

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,

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

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

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

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

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

Re: [DISCUSS] Update default disk_access_mode to mmap_index_only on 5.0

+100 to this We'd have to come up w/ a pretty compelling counterexample to NOT switch the default to mmap_index_only at this point. On Wed, Sep 6, 2023 at 11:40 AM Brandon Williams wrote: > Given https://issues.apache.org/jira/browse/CASSANDRA-17237 I think it > makes sense. At the least I

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

...or like the end of January. Either way, feel free to ignore the "aside" :) On Mon, Oct 23, 2023 at 12:53 PM Caleb Rackliffe wrote: > Kind of in the same place as Benedict/Aleksey. > > If we release a 5.1 in, let's say...March of next year, the number of 5.0 > use

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

Kind of in the same place as Benedict/Aleksey. If we release a 5.1 in, let's say...March of next year, the number of 5.0 users is going to be very minimal. Nobody is going to upgrade anything important from now through the first half of January anyway, right? They're going to be making sure their

Re: [VOTE] Accept java-driver

+1 On Tue, Oct 3, 2023 at 2:49 PM Sylvain Lebresne wrote: > +1 > -- > Sylvain > > > On Tue, Oct 3, 2023 at 8:43 PM Jon Haddad > wrote: > >> +1 >> >> >> On 2023/10/03 04:52:47 Mick Semb Wever wrote: >> > The donation of the java-driver is ready for its IP Clearance vote. >> >

Re: [DISCUSS] Backport CASSANDRA-18816 to 5.0? Add support for repair coordinator to retry messages that timeout

+1 on a 5.0 backport On Wed, Sep 20, 2023 at 2:26 PM Brandon Williams wrote: > I think it could be argued that not retrying messages is a bug, I am > +1 on including this in 5.0. > > Kind Regards, > Brandon > > On Tue, Sep 19, 2023 at 1:16 PM David Capwell wrote: > > > > To try to get repair

Re: Call for Volunteers - Build Lead

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

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,

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

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.

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

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

Re: CEP-15 multi key transaction syntax

>>> >>>> proposals wrt trying to explain this to somebody new. >>> >>>> >>> >>>> Looking at all the options, the first thing that comes up for me is >>> >>>> the Cassandra project's complicated relationship with NULL

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

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,

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,

Re: CEP-15 multi key transaction syntax

;> CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] [keyspace_name.]view_name >> AS SELECT [ (column_list) ] >> FROM [keyspace_name.]table_name >> [ WHERE column_name IS NOT NULL >> [ AND column_name IS NOT NULL ... ] ] >> [ AND relation [ AND ... ] ] >> PRIM

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

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 read

Re: CEP-15 multi key transaction syntax

atives? 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>... > > In SQL, any comp

Re: CEP-15 multi key transaction syntax

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://issues.

Re: [DISCUSSION] New dependencies for SAI CEP-7

We need random generators no matter what for these tests, so I think what we need to decide is whether to continue to use Carrot or migrate those to QuickTheories, along the lines of what we have now in org.apache.cassandra.utils.Generators. When it comes to a library like this, the thing I would

Re: Merging CEP-15 to trunk

Just FYI, I'm going to be posting a Jira (which will have some dependencies as well) to track this merge, hopefully some time today... On Tue, Jan 24, 2023 at 12:26 PM Ekaterina Dimitrova wrote: > I actually see people all the time making a final check before merge as > part of the review. And

Re: Merging CEP-15 to trunk

t ninja commit >> unless it's a comment fix, typo, forgotten git add, or something along >> those lines. For any commit that doesn't qualify it should go through the >> review process. >> >> And a final note - Ekaterina alluded to something valuable in her email >> e

Re: Merging CEP-15 to trunk

wear our Apache > Hats here, and if the debate is between work like this happening in a > feature branch affording contributors increased efficiency and locality vs. > all that happening on trunk and repeatedly colliding with everyone > everywhere, feature branches are a clear win

Re: Cassandra CI Status 2023-01-07

New failures from Build Lead Week 4: *** CASSANDRA-18188 - Test failure in upgrade_tests.cql_tests.cls.test_limit_ranges - trunk - AttributeError: module 'py' has no attribute 'io' *** CASSANDRA-18189 - Test failure in cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_timeouts

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,

Re: Merging CEP-15 to trunk

Just an FYI, the Accord feature flag has landed in the cep-15-accord branch: https://github.com/apache/cassandra/commit/2e680a33c03ce66d4b1358e1a1cc11cf4ee0189f (btw, it implicitly fixes some of the dtests around the new Accord system keyspace, because Accord is now disabled by default.) On Tue,

[DISCUSS] cep-15-accord, cep-21-tcm, and trunk

We've already talked a bit about how and when the current Accord feature branch should merge to trunk. Earlier today, the cep-21-tcm branch was created

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

a prototype of Accord to trunk probably has marketing > value. (Don't laugh, many popular databases have had "atomic transactions, > except if anyone executes DDL simultaneously".) > > On Tue, Mar 14, 2023 at 8:39 PM Caleb Rackliffe > wrote: > > We've already talked a bit &g

Re: [EXTERNAL] [DISCUSS] Next release date

> I worry about the labor involved with having very large work like this target a frozen branch and then also needing to pull it up to trunk. That doesn't sound fun. > I for one do not like to have release branches cut months before their expected release. > CEP-15 is mostly “net new stuff” and

Re: [EXTERNAL] [DISCUSS] Next release date

that it will change so much. Am I > missing something? > > Le ven. 24 mars 2023 à 19:16, Caleb Rackliffe > a écrit : > >> > I worry about the labor involved with having very large work like this >> target a frozen branch and then also needing to pull it

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

opinion on how long we think this would take? Seems like that'd help clarify whether or not there's contributors with the bandwidth and desire to even do that or whether everyone depending on cep-21 is our option.On Fri, Mar 24, 2023, at 1:30 PM, Caleb Rackliffe wrote:I actually did a dry run rebase

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

an informed opinion on how long we think this would take? Seems like that'd help clarify whether or not there's contributors with the bandwidth and desire to even do that or whether everyone depending on cep-21 is our option.On Fri, Mar 24, 2023, at 1:30 PM, Caleb Rackliffe wrote:I actually did a dry

Re: [DISCUSS] Next release date

> Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0 For the record, I'm not convinced this is necessarily better than just cutting a cassandra-5.0 branch on 1 October. On Mon, Apr 17, 2023 at 2:30 AM Mick Semb Wever wrote: > 2. When CEP-15 lands we cut alpha1, >> 2a. The

Re: [DISCUSS] Next release date

> My personal .02: I think we should consider branching 5.0 September 1st. That gives us basically 12 weeks for folks to do their testing and for us to stabilize anything that's flaky in circle or regressed in ASF CI. WFM, if that means we branch there and anything not already merged has to wait

Re: [DISCUSS] Next release date

...or just cutting a 5.0 branch when CEP-21 is ready. There's nothing stopping us from testing JDK17 and TTL bits in trunk before that. On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe wrote: > > Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0 > > For the

Re: [DISCUSS] Next release date

of CEP-15 / CEP-21 after branch, we risk > needing a fast-follow release and don't have functional precedent for the > snapshots we earlier agreed upon doing. > > Does that distill it and match everyone else's understanding? > > On Mon, Apr 17, 2023, at 2:20 PM, Mick Semb Wever

Re: [DISCUSS] Next release date

> Caleb, you appear to be the only one objecting, and it does not appear that you have made any compromises in this thread. All I'm really objecting to is making special exceptions for particular CEPs in relation to our freeze date. In other words, let's not have a pseudo-freeze date and a "real"

Re: [DISCUSS] New data type for vector search

I don’t have a lot to add here, other than to say I’m broadly in agreement w/ David on syntax preference, element selectability, and making this a new type that roughly corresponds to a primitive (non-null-allowing) array.On Apr 27, 2023, at 9:18 PM, Anthony Grasso wrote:It would be strange for

Re: [DISCUSS] CEP-29 CQL NOT Operator

+1 to the proposal from a CQL perspective *However*, whether we do this in the context of simple partition restriction, a global index query, or a partition-restricted index query, the NOT operator is most likely to be useful only in a post-filtering capacity. (ex. WHERE indexed_set CONTAINS {

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

) delay, then that's fine and there's no need to do additional work just to get some preview release out earlier.henrikOn Sat, Mar 25, 2023 at 4:17 AM Caleb Rackliffe <calebrackli...@gmail.com> wrote:I agree there’s little point in litigating right now, given test stability (or lack thereof)

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

KEYSPACE isn’t a terrible name for a namespace that also configures how keys are replicated. NAMESPACE is accurate but not comprehensive. DATABASE doesn’t seem to have the advantages of either.I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me to believe KEYSPACE is really a

Re: [POLL] Vector type for ML

To be clear, I support the general agreement David and Jonathan seem to have reached. On Wed, May 3, 2023 at 3:05 PM Caleb Rackliffe wrote: > Did we agree on a CQL syntax? > > On Wed, May 3, 2023 at 2:06 PM Rahul Xavier Singh < > rahul.xavier.si...@gmail.com> wrote: > &g

Re: [POLL] Vector type for ML

Did we agree on a CQL syntax? On Wed, May 3, 2023 at 2:06 PM Rahul Xavier Singh < rahul.xavier.si...@gmail.com> wrote: > I like this approach. Thank you for those working on this vector search > initiative. > > Here's the feedback from my "user" hat for someone who is looking at > databases /

Status Update on CEP-7 Storage Attached Indexes (SAI)

Hello there! After much toil, the first phase of CEP-7 is nearing completion (see CASSANDRA-16052 ). There are presently two issues to resolve before we'd like to merge the cep-7-sai feature branch and all its goodness to trunk:

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

not something we will develop in tandem with C* releases, and we will want improvements to be applied across all branches.So it seems a natural fit for submodules to me.On 24 May 2023, at 21:09, Caleb Rackliffe wrote:> Submodules do have their own overhead and edge cases, so I am mostly in fa

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

> Submodules do have their own overhead and edge cases, so I am mostly in favor of using for cases where the code must live outside of tree (such as jvm-dtest that lives out of tree as all branches need the same interfaces) Agreed. Basically where I've ended up on this topic. > We could go over

Re: Tokenization and SAI query syntax

me syntax, even > if it means there's two ways of writing the same query. To use Caleb's > example, this would mean supporting both LIKE and the `expr` column. > >> > >> Jon > >> > >>>> On 2023/08/01 19:17:11 Caleb Rackliffe wrote: > >>> Here are

Re: Tokenization and SAI query syntax

Here are some additional bits of prior art, if anyone finds them useful: The Stratio Lucene Index - https://github.com/Stratio/cassandra-lucene-index#examples Stratio was the reason C* added the "expr" functionality. They embedded something similar to ElasticSearch JSON, which probably isn't my

Re: Status Update on CEP-7 Storage Attached Indexes (SAI)

rebase on the current trunk and J11 and J17 test runs. On Tue, Jul 18, 2023 at 3:47 PM Caleb Rackliffe wrote: > Hello there! > > After much toil, the first phase of CEP-7 is nearing completion (see > CASSANDRA-16052 <https://issues.apache.org/jira/browse/CASSANDRA-16052>). > The

Re: Status Update on CEP-7 Storage Attached Indexes (SAI)

t 6:07 AM Jeremy Hanna wrote: > Thanks Caleb and Mike and Zhao and Andres and Piotr and everyone else > involved with the SAI implementation! > > On Jul 25, 2023, at 3:01 PM, Caleb Rackliffe > wrote: > >  > Just a quick update... > > With CASSANDRA-18670 > <h

Re: [DISCUSS] CASSANDRA-18743 Deprecation of metrics-reporter-config

+1 > On Aug 11, 2023, at 8:10 AM, Brandon Williams wrote: > > +1 > > Kind Regards, > Brandon > >> On Fri, Aug 11, 2023 at 8:08 AM Ekaterina Dimitrova >> wrote: >> >> >> “ The rationale for this proposed deprecation is that the upcoming 5.0 >> release is a good time to evaluate

Re: Tokenization and SAI query syntax

> >> An (maybe better?) alternative is to add a flag to the index >> configuration for "compatibility mod", which might address the concerns >> around using an equality operator when it actually is a partial match. >> >> For what it's worth, I'm in a

Re: Tokenization and SAI query syntax

ing how differing behavior for the same syntax can lead to >>> issues. Imo the best case scenario results in the user not even noticing >>> their indexes have changed. >>> >>> An (maybe better?) alternative is to add a flag to the index >>

Re: [DISCUSS] The future of CREATE INDEX

For everyone previously following this, just created https://issues.apache.org/jira/browse/CASSANDRA-18615 :) On Fri, May 19, 2023 at 1:34 PM Caleb Rackliffe wrote: > Posted on ASF Slack to see if we can get more responses, but so far the > leaders seem to be... > > [POLL] Central

Re: [VOTE] CEP-8 Datastax Drivers Donation

+1 On Tue, Jun 13, 2023 at 11:25 AM Francisco Guerrero wrote: > +1 (nb) > > On 2023/06/13 16:22:55 Andrés de la Peña wrote: > > +1 > > > > On Tue, 13 Jun 2023 at 16:40, Yifan Cai wrote: > > > > > +1 > > > -- > > > *From:* David Capwell > > > *Sent:* Tuesday, June

Re: CEP-30: Approximate Nearest Neighbor(ANN) Vector Search via Storage-Attached Indexes

Anyone on this ML who still remembers DSE Search (or has experience w/ Elastic or SolrCloud) probably also knows that there are some significant pieces of an optimized scatter/gather apparatus for IR (even without sorting, which also doesn't exist yet) that do not exist in C* or it's range query

[DISCUSS] The future of CREATE INDEX

Earlier today, Mick started a thread on the future of our index creation DDL on Slack: https://the-asf.slack.com/archives/C018YGVCHMZ/p1683527794220019 At the moment, there are two ways to create a secondary index. *1.) CREATE INDEX [IF NOT EXISTS] [name] ON ()* This creates an optionally

Re: [DISCUSS] The future of CREATE INDEX

g extra ceremony. >> >> On Tue, May 9, 2023 at 5:20 PM Jeremiah D Jordan < >> jeremiah.jor...@gmail.com> wrote: >> >>> If the consensus is that SAI is the right default index, then we should >>> just change CREATE INDEX to be SAI, and legacy 2i to be a CU

  1   2   >