Re: Status of CEP-1

Currently the Sidecar has a lot of functionality that is immediately usable by the community. Apart from minor fixes, the AuthN/Z story would be wrapped up soon. Post this, I would propose moving forward with cutting a release with the existing feature set so we can get this in the hands of our com

Re: [DISCUSS] Modeling JIRA fix version for subprojects

To play devil's advocate here, it's important that the subprojects don't lose visibility and silo from the rest of the project. There are different ways to solve this, and lumping everything into one jira project is a messy and poor way of doing it. But as the sidecar has shown us, subproject act

Re: [DISCUSS] Modeling JIRA fix version for subprojects

Also, many Jira reports are based off Jira projects. So mixing everything in one bag makes those unusable. But more importantly future Jira features/integrations/etc will probably be project oriented as well and they might become difficult or unusable to us. My 2cts. On 1/10/24 23:44, Yifan

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

It's certainly an improvement/optimization, so I wouldn't object to it being in 5.0.x. I have no plans to touch the outstanding ways ALLOW FILTERING is broken until I get to CASSANDRA-19007 , which hopefully happens soon. On Tue, Oct 1, 2024 a

Re: Status of CEP-1

Have the same question ： what ‘s the plan ？ Jeff Jirsa 于2024年10月2日 周三上午10:43写道： > > > On Oct 1, 2024, at 7:26 PM, Josh McKenzie wrote: > > However it is used by a number of other features as a dependency such as > analytics, backup/restore, repair, metrics, and CDC > > It seems like a natural pr

Re: Status of CEP-1

> On Oct 1, 2024, at 7:26 PM, Josh McKenzie wrote: > >> However it is used by a number of other features as a dependency such as >> analytics, backup/restore, repair, metrics, and CDC > It seems like a natural pressure relief valve for moving operations out of a > core C* node that are well s

Re: Status of CEP-1

> However it is used by a number of other features as a dependency such as > analytics, backup/restore, repair, metrics, and CDC It seems like a natural pressure relief valve for moving operations out of a core C* node that are well served out of process. On Tue, Oct 1, 2024, at 4:52 PM, Jeremy

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

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, Oct 1, 2024 at 1:31 PM Caleb Rackliffe > wrote: > >> Alrighty, with what looks like a fair amount of

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

Agreed this would absolutely be a win. Dont see need for a flag either. On Tue, Oct 1, 2024 at 1:31 PM Caleb Rackliffe wrote: > Alrighty, with what looks like a fair amount of support, I'll declare > CASSANDRA-19968 ready > for some prelimi

Re: [DISCUSS] Modeling JIRA fix version for subprojects

I support the idea of having separate Jira projects. Based on my experience with both shared namespaces (like Cassandra and Analytics) and dedicated namespaces (like Sidecar), I've seen the drawbacks of grouping all subproject tickets under a single project, i.e. Cassandra. When tickets are consol

DefaultDriverOption default values

Hello I am using Datastax Java driver for Apache Cassandra, and programmatic session builder. I can't find what are the default values of configs listed in DefaultDriverOption ( https://docs.datastax.com/en/drivers/java/4.13/com/datastax/oss/driver/api/core/config/DefaultDriverOption.html), for ex

Re: Status of CEP-1

The odd thing about the sidecar is that it wasn’t an end in itself. However it is used by a number of other features as a dependency such as analytics, backup/restore, repair, metrics, and CDC.I agree with Jeremiah about a 1.0 shippable version. Is there anything else needed in the current sidecar

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

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

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

Did we add new metrics for index queries? The only issue I see is that this change will mix index queries into the regular read metrics, where before they were in the range metrics, so maybe some changes to metrics should go with it. But I think this is a good change over all. On Oct 1, 2024 at

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

We did add CASSANDRA-18940 to make sure local SAI post-filtering reads got picked up somewhere, but you're right that StorageProxy#readRegular() would start recording some index queries in the normal read metrics. On Tue, Oct 1, 2024 at 2:11 

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

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: > > (Higher rate of mismatches requiring a second full read? Why would 2i be > more likely?) > > Right, I don't see any reason they should be more likely to actu

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

> (Higher rate of mismatches requiring a second full read? Why would 2i be more likely?) Right, I don't see any reason they should be more likely to actuate read-repair than slice queries are today... Didn't mention this above, but I'd obviously be open to having a system property that switches t

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

> On Oct 1, 2024, at 10:28 AM, Caleb Rackliffe wrote: > > 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.

[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: Status of CEP-1

I don’t really have an opinion on re-writing the existing one vs closing that and making a new one. But I do think we should have some CEP describing the "1.0 shippable version" of the side car that is being proposed, then it can have a VOTE thread, and there will be no issues voting the release m

Re: DefaultDriverOption default values

The user list is a more appropriate place for this kind of question. Here’s the default reference.conf configuration file: https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/resources/reference.conf Docs on configuration here: https://github.com/apache/cassandra-java-driver/

Re: Status of CEP-1

> CEP-1 is still completely relevant and we could send an update CEP-1 feels really fat compared to all our other CEP's. When you need a table to enumerate all the subsets of things you're going to do with something so you can keep track of progress... it might be too large. :D If we think we ca

Re: [DISCUSS] Modeling JIRA fix version for subprojects

What is the status of this thread? Are we looking to move each driver project to its own jira instance, as voted for in CEP-8? Kind Regards, Brandon On Tue, Apr 9, 2024 at 9:29 AM Brandon Williams wrote: > > I am +1 on separate projects as well, but to Abe's point I don't think > it matters now,

Re: [DISCUSS] Modeling JIRA fix version for subprojects

CEP-8 says "We suggest distinct Jira projects, one per driver, all to be created." Kind Regards, Brandon On Tue, Oct 1, 2024 at 9:23 AM Jon Haddad wrote: > > My 2 cents - trying to look through C* JIRA right now is kind of awful with > different projects all mixed in. Given that the decision t

Re: [DISCUSS] Modeling JIRA fix version for subprojects

My 2 cents - trying to look through C* JIRA right now is kind of awful with different projects all mixed in. Given that the decision to lump everything together seems to have been made unilaterally, against the VOTE, I'd say we still need to move drivers off CASSANDRA. Only question is, one for a

Re: [DISCUSS] CEP-44: Kafka integration for Cassandra CDC using Sidecar

It seems this has triggered some important discussions about CEP-1 and the Sidecar. Let's keep those in their respective threads and focus this conversation on CEP-44. Patrick, I think I missed your point "There is also little mention of where the increased resource load would be handled." - you'r