+1
> On Dec 19, 2022, at 6:28 PM, Jake Luciani wrote:
>
>
> +1
>
>> On Mon, Dec 19, 2022 at 7:27 PM C. Scott Andreas
>> wrote:
>> +1nb
>>
>>> On Dec 19, 2022, at 1:27 PM, Josh McKenzie wrote:
>>>
>>>
>>> +1
>>>
On Mon, Dec 19, 2022, at 11:54 AM, SAURABH VERMA wrote:
+1
I’m also very interested in this area. I quickly skimmed the proposal and IIUC it doesn’t call for moving away from JMX. Instead I think it’s making it easier to expose metrics over various interfaces. Maxim please correct me if I’m wrong in my understanding.I also second Josh’s point on JMX usage.
Congratulations Patrick!
>
> On Feb 2, 2023, at 9:58 AM, Benjamin Lerer wrote:
>
>
> 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
> commu
+1
>
> On Feb 6, 2023, at 8:16 AM, Sam Tunnicliffe wrote:
>
>
> Hi everyone,
>
> I would like to start a vote on this CEP.
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
>
> Discussion:
> https://lists.apache.org/thread/h25skw
I’m a big fan of maintaining backward compatibility. Downgradability implies that we could potentially roll back an upgrade at any time. While I don’t think we need to retain the ability to downgrade in perpetuity it would be a good objective to maintain strict backward compatibility and therefore
Hi Benjamin,
I agree with your concern about long term maintenance of the code. Doug
has contributed several patches to Cassandra over the years. Besides him
there will be several other maintainers that will take on maintenance of
this code including Yifan and myself. Given how closely it is coupl
Thank you Mick for all the work you did!
Welcome Josh and congratulations!
On 3/23/23 01: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 next PMC Chair Josh McKe
I’m strongly in favor of leaving terminology as-is. On Apr 6, 2023, at 7:20 AM, Bowen Song via dev wrote:
> I'm quite happy to leave things as they are if that is
the consensus.
+1 to the above
On 06/04/2023 14:54, Mike Adamson
wrote:
-1 as well. We need to upgrade Zstd.
>
> On Apr 6, 2023, at 4:57 AM, Mick Semb Wever wrote:
>
>
>
>
>> Up to you to fail the vote and we realistically release 4.0.9 after Easter
>
>
> -1 to the vote.
>
> I support your initial veto and reasoning, and it appears you are willing to
> re
Interesting proposal Jonathan. Will grok it over the weekend and play around
with the branch.
Do you intend to make this part of CEP-7 or as an incremental update to SAI
once it is committed?
> On Apr 21, 2023, at 2:19 PM, Jonathan Ellis wrote:
>
> Happy Friday, everyone!
>
> Rich text forma
Does anybody have any questions that we could answer about this proposal?
> On Apr 27, 2023, at 1:24 PM, Francisco Guerrero
> wrote:
>
> Hi folks,
>
> We have updated the confluence page with the source code for CEP-28.
> There are two repositories with contributions. One is the patch [1]
> fo
27;ve seen so far are for the sidecar streaming
> sstables (seems like this is just network bound?). What kind of perf are
> you seeing at the Spark executors (at the per task level)?
>
> --Seb
>
> On Mon, May 1, 2023 at 3:50 PM Dinesh Joshi wrote:
>
> > Does anybod
Yeah it makes sense that the sstable streaming is network bound since it's
> mostly just moving files.
>
> Do you have any performance stats on the sstable parsing side inside spark?
>
> --Seb
>
> On Tue, May 2, 2023 at 3:31 PM Dinesh Joshi wrote:
>
> > It is li
I'm also in favor of having a general data type that is not tied to numeric
data types alone.
On 2023/05/02 22:27:24 Jonathan Ellis wrote:
> I had a call with David. We agreed that we want a "vector" data type with
> these properties
>
> - Fixed length
> - No nulls
> - Random access not support
If there aren't additional questions / comments I will start the VOTE thread on
this CEP tonight.
On 2023/05/01 19:50:12 Dinesh Joshi wrote:
> Does anybody have any questions that we could answer about this proposal?
ersion. I think everyone will definitely not want the
> project code to be merged, but it has been unable to release for a long time
> as this project relies on Cassandra sidecar.
>
> Dinesh Joshi mailto:djo...@apache.org>> 于2023年5月4日周四
> 02:35写道：
>> If there aren't
+1
> On May 4, 2023, at 9:46 AM, Doug Rohrer wrote:
>
> Hello all,
>
> I’d like to put CEP-28 to a vote.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics
>
> Jira:
> https://issues.apache.org/jira/b
+1
> On May 8, 2023, at 1:52 AM, Piotr Kołaczkowski wrote:
>
> Let's vote.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
I agree. 5.0 is a major release and provides an opportunity to switch defaults.
> On May 9, 2023, at 7:00 PM, Jonathan Ellis wrote:
>
> +1 for this, especially in the long term. CREATE INDEX should do the right
> thing for most people without requiring extra ceremony.
>
> On Tue, May 9, 2023
> On May 12, 2023, at 11:36 AM, Caleb Rackliffe
> wrote:
>
> [POLL] Centralize existing syntax or create new syntax?
>
> 1.) CREATE INDEX ... USING WITH OPTIONS...
> 2.) CREATE LOCAL INDEX ... USING ... WITH OPTIONS... (same as 1, but adds
> LOCAL keyword for clarity and separation from
Proposing the test build of in-jvm dtest API 0.0.14 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
Candidate SHA:
https://github.com/apache/cassandra-in-jvm-dtest-api/commit/ea4b44e0ed0a4f0bbe9b18fb40ad927b49a73a32
tagged with 0.0.14
Artifacts:
http
Vote passes with 7 +1s and no -1s.
thanks everybody.
On 5/15/23 15:12, Dinesh Joshi wrote:
> Proposing the test build of in-jvm dtest API 0.0.14 for release.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
>
> Candidate SHA:
> http
Proposing the test build of in-jvm dtest API 0.0.15 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
Candidate SHA:
https://github.com/apache/cassandra-in-jvm-dtest-api/commit/48af78d1d4b5f285d3dd4991afd4df3101e3983a
tagged with 0.0.15
Artifacts:
http
> On May 25, 2023, at 6:14 AM, Jonathan Ellis wrote:
>
> Any objections to adding the concurrent wrapper and switching out agrona for
> fastutil?
How does fastutil compare to agrona in terms of memory profile and runtime
performance? How invasive would it be to switch?
ex Petrov wrote:
>> > +1
>> >
>> > On Wed, May 24, 2023, at 5:36 PM, Doug Rohrer wrote:
>> > > +1 (nb)
>> > >
>> > > > On May 24, 2023, at 11:32 AM, Brandon Williams > > > > <mailto:dri...@gmail.com>> wrote:
&
Leaving the naming aside (the hardest part of any software), I am generally
positive about your idea. A protocol version bump may be avoidable like you
suggested. Perhaps a prototype of this idea is in order to help shape the idea?
Would you like to take it on?
> On May 21, 2023, at 4:21 AM, De
+1On May 25, 2023, at 8:45 AM, Jonathan Ellis wrote:Let's make this official.CEP: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-30%3A+Approximate+Nearest+Neighbor%28ANN%29+Vector+Search+via+Storage-Attached+IndexesPOC that demonstrates all the big rocks, including distributed queries:
This is exciting. Thank you for all your hard work on getting ICLAs from contributors. I am in favor of moving forward.On May 26, 2023, at 5:54 AM, Jeremy Hanna wrote:To add to a somewhat crowded [DISCUSS] party, I'd like to restart the discussion around CEP-8.This is the original thread from Jul
Hi dev@,
We're planning to add mTLS client authentication as well as internode
authentication in CASSANDRA-18554. While this is all backward compatible, we
thought it would be a good idea to notify the dev list. If anybody is
interested please take a look at the JIRA.
Thanks,
Dinesh
> Is there an expectation that this would be used alongside internode and
> client TLS? Would the certificates be the same, different, or is that an
> implementation detail for the specific deployment to determine?
I am not sure what you mean by this would be used alongside internode and
client
> On Jun 2, 2023, at 1:56 PM, Christopher Bradford wrote:
>
> I am not sure what you mean by this would be used alongside internode and
> client TLS? The mutual TLS authentication allows the server to authenticate
> the client's identity using a client TLS certificate. The authenticators
> we'
> On Jun 2, 2023, at 9:06 PM, Derek Chen-Becker wrote:
>
> This certainly looks like a nice addition to the operator's tools for
> securing cluster access. Out of curiosity, is there anything in this work
> that would *preclude* a different authentication scheme for internode at some
> point i
+1
Dinesh
> On 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 discussion thread [2], the
> goal of this vote is simply to ensure that the community is in favor of the
> donation. Nothing more.
> The pl
ounds great, thanks for the clarification!
>
> Cheers,
>
> Derek
>
> On Sat, Jun 3, 2023 at 12:48 AM Dinesh Joshi <mailto:djo...@apache.org>> wrote:
>
>> On Jun 2, 2023, at 9:06 PM, Derek Chen-Becker
>> mailto:de...@chen
This would be a good addition and would make Cassandra more performant out of the box.DineshOn Jun 22, 2023, at 9:45 PM, Jordan West wrote:Glad to see there is support for this! I think ACCP would be a good choice since there seems to be a lot of experience deploying it. I’ve opened https://issue
+1On Jun 27, 2023, at 1:23 PM, Josh McKenzie wrote:+1On Tue, Jun 27, 2023, at 1:17 PM, Shailaja Koppu wrote:Hi Team,(Starting a new thread for VOTE instead of reusing the DISCUSS thread, to follow usual procedure).Please vote on CEP 33 - CIDR filtering authorizer https://cwiki.apache.org/confluen
ySQL
>> offers:
>>
>> CREATE USER 'jeffrey'@'localhost'
>> REQUIRE SUBJECT
>> '/C=SE/ST=Stockholm/L=Stockholm/
>>
> It is surprising to me that we load the identity from the keystore vs
> explicitly setting an expected value in cassandra.yaml. I get that an error
> is thrown if the identity doesn't match those of other nodes in the cluster,
> but does it make sense to prevent startup should the value in the
> On Jun 30, 2023, at 1:09 PM, Jeremiah Jordan wrote:
>
> I don’t think users necessarily need to be able to update their own
> identities. I just don’t want to have to use the super user role. The super
> user role has all power over all things in the data base. I don’t want to
> have to g
> On Jul 8, 2023, at 8:43 AM, Miklosovic, Stefan
> wrote:
>
> If we are providing CQL / JSON / YAML for couple years, I do not believe that
> the argument "lets not break it for folks in nodetool" is still relevant. CQL
> output is there from times of 4.0 at least (at least!) and YAML / JSON
d be a convenient feature, we can add it as required in the followup patches.Christopher, I will be acting upon your feedback regarding having identity in the cassandra.yaml optionally configurable.Thanks,Jyothsna Konisa.On Thu, Jul 6, 2023 at 5:30 PM Dinesh Joshi <djo...@apache.org> wrote:&
I can certainly start a VOTE thread for the CQL syntax addition. There
hasn't been any feedback that suggests that there is an unaddressed
concern to the changes we are making.
That said, I'm not sure if there was explicit decision that has resulted
in an update to the project's governance to refl
This adds maintenance overhead but is a potential alternative. I would only
flip the flag. I would prefer to make the default "legacy" output and innovate
behind a "--output-format=v2" flag. That way tools do not break or have to
change to pass in the new flag.
Ideally we should always version
+1
> On Jul 13, 2023, at 12:12 AM, Miklosovic, Stefan
> wrote:
>
> Proposing the test build of Cassandra 4.0.11 for release.
>
> sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5
> Git: https://github.com/apache/cassandra/tree/4.0.11-tentative
> Maven Artifacts:
> https://repository.apache.org/c
nd start a VOTE thread for it.
Thanks,
Dinesh
> On Jul 12, 2023, at 12:13 AM, Dinesh Joshi wrote:
>
> I can certainly start a VOTE thread for the CQL syntax addition. There
> hasn't been any feedback that suggests that there is an unaddressed
> concern to the changes we are m
Does anybody have any questions / comments?
Dinesh
> On Jul 17, 2023, at 12:37 PM, Dinesh Joshi wrote:
>
> Hi folks,
>
> Given the feedback received, we thought it would be best to do a CEP. Here's
> the link: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-
+1
> On Jul 18, 2023, at 11:28 PM, Miklosovic, Stefan
> wrote:
>
> Proposing the test build of Cassandra 4.1.3 for release.
>
> sha1: 2a4cd36475de3eb47207cd88d2d472b876c6816d
> Git: https://github.com/apache/cassandra/tree/4.1.3-tentative
> Maven Artifacts:
> https://repository.apache.org/c
Thanks Francisco, Mick and Yifan for making this happen!
> On Jul 20, 2023, at 4:00 PM, Francisco Guerrero wrote:
>
> Hi list,
>
> I wanted to bring some visibility into the Cassandra Sidecar CI health [1].
> It seems like it has been broken for quite a while and we have finally fixed
> it toda
+1
> On Jul 21, 2023, at 11:07 AM, Francisco Guerrero wrote:
>
> +1 (nb). This is a very valuable enhancement for the project.
>
> Thanks for the contribution, Jyothsna!
>
> On 2023/07/21 16:57:45 Jyothsna Konisa wrote:
>> Hi Everyone!
>>
>> I would like to start a vote thread for CEP-34.
>>
I concur, repair is an intrinsic part of the database and belongs inside it. We
can certainly expose a REST control plane API via the sidecar for triggering it
on demand, scheduling, etc.
That said, there are various implementation of repair scheduling and
orchestration that a lot of organizati
Mick,
This sounds like a good plan. CEP-33 and 34 are ready to go. We're running into
CI related issues but once they clear up we'll merge them. I anticipate we'll
be done in a week's time.
Thanks,
Dinesh
> On Jul 26, 2023, at 3:27 PM, Mick Semb Wever wrote:
>
>
> The previous thread¹ on w
+1 to on by default.
I see the concern about breaking users by introducing 'silent defaults'. IMO
ACCP itself is a non-breaking change. If I have missed something please point
it out and I'll happy to reconsider my position.
The advantages of having ACCP on by default far outweigh the risk of n
Brad,
Thanks for starting this discussion. My understanding is that we're
simply adding pip support for cqlsh and Apache Cassandra project will
officially publish a cqlsh pip package. This is a good goal but other
than having an official pip package, what is it that we're gaining?
Please don't int
Proposing the test build of in-jvm dtest API 0.0.16 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
Candidate SHA:
https://github.com/apache/cassandra-in-jvm-dtest-api/commit/1ba6ef93d0721741b5f6d6d72cba3da03fe78438
tagged with 0.0.16
Artifacts:
http
don Williams wrote:
>>> +1
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>> On Wed, Aug 16, 2023 at 4:34 PM Dinesh Joshi >> <mailto:djo...@apache.org>> wrote:
>>> >
>>> > Proposing the test bui
+1
This is great for the project. Thank you for all the hard work everyone put
into this! It has been a long journey to get to this point.
Dinesh
> On Oct 2, 2023, at 9:53 PM, Mick Semb Wever wrote:
>
>
> The donation of the java-driver is ready for its IP Clearance vote.
> https://incubato
I haven't looked at the patch yet so take whatever I say here with a pinch of
salt.
Philosophically, defaults should not change unless there is a clear
demonstrable benefit in majority cases for our users. In this case DirectIO
should have clear benefits. That said, this is a new feature and I
I have a strong preference to move out the 5.0 date to have accord and TCM. I
don’t see the point in shipping 5.0 without these features especially if 5.1 is
going to follow close behind it.
Dinesh
> On Oct 23, 2023, at 4:52 AM, Mick Semb Wever wrote:
>
>
>
> The TCM work (CEP-21) is in it
Hi Maxim,
Thanks for putting this CEP together! This is a great start. I have gone over
the CEP and there is one thing that stuck out to me.
Among the 'basic requirements', I see you have this -
> A dedicated admin port with the native protocol behind it,
> allowing only admin commands, to add
The PMC members are pleased to announce that Francisco Guerrero Hernandez has
accepted
the invitation to become committer today.
Congratulations and welcome!
The Apache Cassandra PMC members
+1On Dec 8, 2023, at 11:43 PM, Mick Semb Wever wrote:Proposing the test build of Cassandra Java Driver 4.18.0 for release.sha1: 105d378fce16804a8af4c26cf732340a0c63b3c9Git: https://github.com/apache/cassandra-java-driver/tree/4.18.0Maven Artifacts:https://repository.apache.org/content/repositorie
> On Dec 14, 2023, at 10:32 AM, Ariel Weisberg wrote:
>
> 1. Fork OHC and start publishing under a new package name and continue to use
> it
Who would fork it? Where would you fork it? My first instinct is that this
would not be viable path forward.
> 2. Replace OHC with a different cache imp
I would avoid taking away a feature even if it works in narrow set of
use-cases. I would instead suggest -
1. Leave it disabled by default.
2. Detect when Row Cache has a low hit rate and warn the operator to turn it
off. Cassandra should ideally detect this and do it automatically.
3. Move to C
> On Dec 14, 2023, at 5:35 PM, Paulo Motta wrote:
>
> This could be a potential hook for out-of-process caching.
>
> Would something like this be valuable/feasible?
It is certainly feasible. I am not sure about its value.
Dinesh
thanks for the heads up. Is there anything we could do to avoid bad merges in
the future?
Dinesh
> On Dec 16, 2023, at 3:26 PM, Mick Semb Wever wrote:
>
>
> The cassandra-5.0 branch accidentally got 229 trunk merge commits brought
> into it.
>
> This has been fixed now, but required a force
> On Dec 11, 2023, at 11:27 AM, Raymond Huffman
> wrote:
>
> On our fork of Cassandra, we've implemented some custom behavior for handling
> CommitLog and SSTable Corruption errors. Specifically, if a node detects one
> of those errors, we want the node to stop itself, and if the node is
> re
Shylaja,
Cassandra uses ZStd, LZ4 and other compression libraries via JNI to
compress data. The intel hardware accelerator support is integrated into
those libraries and we can benefit from it. If there are special parameters
that need to be passed in to these libraries we can make those changes o
e hardware which are not compatible with zlib. With this approach we
> could enable those features as well.
>
>
>
> We are also planning to accelerate existing compressors, if that is the
> preferred approach we will try to come up with a solution to work around
> the 4k window
Hi Gaurav,
Thank you for the document. I read through it and wasn't entirely clear
about the problem you're trying to solve.
If you're talking about enabling authentication for the very first time on
a cluster which does not have any authentication then there are different
ways of handling it.
>
hi folks - sorry to have dropped the ball on responding to this thread.
My 2 cents are as follows -
1. Having a separate JIRA project for each sub-project will add management
overhead. This option, however, allows us to model unique workflows for the
sub-project.
2. Managing the sub-project as p
If we take this on - are there any active contributors that can be raised
as committers to maintain this project?
On Wed, Apr 3, 2024 at 2:36 PM Nate McCall wrote:
> We've talked through this before. Benjamin sussed out the main issue,
> IIRC.
> tl,dr:
> - The AUTHORS lists everyone who ever mad
On Mon, Apr 8, 2024 at 10:23 AM Jon Haddad wrote:
> This seems like a lot of work to create an rsync alternative. I can't
> really say I see the point. I noticed your "rejected alternatives"
> mentions it with this note:
>
I want to point out a few things before dismissing it as an 'rsync
alte
On Fri, Apr 19, 2024 at 3:12 PM Jon Haddad wrote:
> I haven't looked at streaming over TLS, so I might be way off base here,
> but our own docs (
> https://cassandra.apache.org/doc/latest/cassandra/architecture/streaming.html)
> say ZCS is not available when using encryption, and if we have to br
On Thu, Apr 18, 2024 at 12:46 PM Ariel Weisberg wrote:
>
> If there is a faster/better way to replace a node why not have Cassandra
> support that natively without the sidecar so people who aren’t running the
> sidecar can benefit?
>
I am not the author of the CEP so take whatever I say with a
I am not familiar with ECS but if we’re going to go for it I would prefer
it to be a sub project really. Jon, what do you think?
On Thu, Apr 25, 2024 at 2:44 PM Brandon Williams wrote:
> I want to begin by saying I am generally +1 on this because I have
> become a fan of easy-cass-stress after u
On Tue, Apr 23, 2024 at 11:37 AM Venkata Hari Krishna Nukala <
n.v.harikrishna.apa...@gmail.com> wrote:
> reason why I called out binary level verification out of initial scope is
> because of these two reasons: 1) Calculating digest for each file may
> increase CPU utilisation and 2) Disk would a
FYI, if anybody is interested in this event today is the registration
deadline.
-- Forwarded message -
From: Battula, Brahma Reddy
Date: Mon, Apr 29, 2024 at 10:27 AM
Subject: Re: Save the Date: Apache At Visa Summit on May 16, 2024 (
Registration Open.)
To: d...@community.apache.
On Tue, May 14, 2024 at 10:05 AM Mick Semb Wever wrote:
>
> Ok, so we're got confidence now on how to approach this, confirmation from
> the project's maintainers supporting it, and interest from a handful of
> people interested in maintaining and contributing to the project.
>
Did you talk to t
On Wed, May 15, 2024 at 12:09 AM Mick Semb Wever wrote:
> Yes Dinesh. João Reis managed to get hold of both Chris and Martin.
>>> Responses have been slow, but everyone is on board. This is not to be
>>> considered a hostile fork, despite in all likelihood not being able to do a
>>> full IP do
+1
On Fri, May 17, 2024 at 10:53 AM Brandon Williams <
brandonwilli...@apache.org> wrote:
> Friendly reminder that this vote is still open and lacks one binding
> vote to pass.
>
> On Thu, May 2, 2024 at 11:36 AM Brandon Williams
> wrote:
> >
> > Proposing the test build of Cassandra 4.1.5 for r
+1
verified hashes and signatures.
On Tue, May 21, 2024 at 4:00 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
> appears that the Nexus staging repository for the 4.18.1 release was
> a
On Thu, Jun 6, 2024 at 1:03 PM Štefan Miklošovič <
stefan.mikloso...@gmail.com> wrote:
> It is interesting to see this feedback. When I look at CEP-24 where I am
> obsessing about a user being able to misconfigure the password validation
> strength so if a user hits a "weak" node then she would be
On Thu, Jun 6, 2024 at 1:50 PM Bernardo Botella <
conta...@bernardobotella.com> wrote:
> I will update the CEP being specific with the two specific Constraint
> types I will be adding, which are size and value (the ones shown in the
> example).
>
Could you identify constraints for the most common
+1.
I have some minor feedback on how the configuration of different character
classes works but that can be handled during the patch review.
On Mon, Jun 17, 2024 at 2:32 AM Štefan Miklošovič
wrote:
> Hi everyone,
>
> I would like to start the voting for CEP-24 as all feedback in the
> discussi
jeremiah.jor...@gmail.com> wrote:
>>>>
>>>> Welcome to the Chair role Dinesh! Congrats!
>>>>
>>>> On Jun 20, 2024 at 10:50:37 AM, Josh McKenzie
>>>> wrote:
>>>>
>>>>> Another PMC Chair baton pass incoming! On
This would be a great contribution to have for the Analytics subproject.
The current bulk functionality in the Analytics subproject complements the
spark-cassandra-connector so I see it as a good fit for donation.
On Mon, Jun 24, 2024 at 12:32 AM Mick Semb Wever wrote:
>
> What are folks thought
+1 on Doug's suggestion. The operator sets a limit that application
developers should not be allowed to violate. This is precisely the type of
safety that we should strive for.
To Jordan's point, I also agree that the read before write type of
constraints should be avoided but if there is a very g
On Tue, Jun 25, 2024 at 10:59 AM Josh McKenzie wrote:
>
> My intuition is the vote got called a *smidge* early but that things are
> very much moving in the right direction and are very close.
>
Agreed and the vote thread got us more feedback which is valuable :)
+1
Thank you Mick and everyone else involved in this effort.
On Tue, Jun 25, 2024 at 11:12 AM Jeff Jirsa wrote:
> +1
>
> Thank you for being explicit about which authors of gocql have signed the
> ICLA
>
> > Where The Gocql Authors for copyright purposes are below. Those marked
> with
> > aster
Abe, that's a good point. We need to call out distinct use-cases here. When
a fresh cluster is set up with constraints we don't have any issues because
the data written and read back is going to be compliant to the
constraint(s). For existing data in a cluster where new constraints are
applied or e
t;
>> I probably have not kept myself up to date with the discussion but I was
>> thinking that constraints are effectively there just on the write path.
>> Whatever is read is not a job of a constraint to refuse to return.
>>
>> On Tue, Jun 25, 2024 at 9:57 PM Dine
I don't personally think there is a strong need for a feature branch. If it
makes it easy for you, please go ahead with a feature branch.
One thing I had raised in the past was the desire to have a flag that would
generate machine readable output for nodetool commands. If this can be done
with a m
+1
On Mon, Jul 1, 2024 at 11:58 AM Ariel Weisberg wrote:
> Hi,
>
> I am +1 on CEP-42 with the latest updates to the CEP to clarify syntax,
> error messages, constraint naming and generated naming, alter/drop,
> describe etc.
>
> I think this now tracks very closely to how other SQL databases def
ted library, we will need a DISCUSS
>> thread to add that new library (current protocol). This mostly just makes
>> the pick more visible, and normally we only check simple things like “are
>> we legally allowed to use” and “is this project dead?”.
>> >
>>
> We need to pick libraries based on their merits. Apple's draconian rules
> should not prevent us from using the best option available.
>
> Jon
>
>
> On Mon, Jul 8, 2024 at 12:57 PM Dinesh Joshi wrote:
>
>> I agree, having a DISCUSS thread with a specific subje
> On Jul 10, 2018, at 10:18 AM, Jonathan Haddad wrote:
>
> I guess I look at the initial voting in of committers as the process
> by which people are trusted to merge things in. This proposed process
> revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily
> picked) wants to merge
+1
> On Jul 13, 2018, at 7:48 PM, Sumanth Pasupuleti
> wrote:
>
> +1 nb
> On Fri, Jul 13, 2018 at 6:58 PM Jaydeep Chovatia
> wrote:
>
>> +1
>>
>> On Wed, Jul 11, 2018 at 2:46 PM sankalp kohli
>> wrote:
>>
>>> Hi,
>>>As discussed in the thread[1], we are proposing that we will not
>> br
> On Aug 16, 2018, at 9:27 PM, Sankalp Kohli wrote:
>
> I am bumping this thread because patch has landed for this with repair
> functionality.
>
> I have a following proposal for this which I can put in the JIRA or doc
>
> 1. We should see if we can keep this in a separate repo like Dtest.
Thanks, Nate. I’ll create this request.
Dinesh
On Aug 17, 2018, at 5:09 PM, Nate McCall wrote:
>> I'm not sure logistically how we get a new repo created and licensing and
>> such, but if someone helps make it we can cut the patch against it
>>
> This is pretty straight forward. For precedent,
> On Aug 22, 2018, at 7:23 PM, Mick Semb Wever wrote:
>
> There's a cost-optimisation here in reducing what we have to support.
I agree and animal sniffer is a great way to ferret out obvious issues. I am
not against using animal sniffer. I'm concerned that there are various
incompatibilities[
1 - 100 of 346 matches
Mail list logo
