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

[Bernardo Botella]

Hi everyone,

I’d like to make one final round of feedback request for this CEP-44: Kafka 
integration for Cassandra CDC using Sidecar before calling in a vote. We’ll 
leave it open for a few more days, and if nothing else comes in, we will call 
in a vote. 

Bernardo

> On Oct 1, 2024, at 6:58 AM, James Berragan  wrote:
> 
> 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're right, running CDC in 
> the Sidecar implicitly means it uses additional resources in the C* cluster. 
> This resource usage is proportional to the write throughput, so it's not 
> suitable for use cases with very high write throughput, but our experience 
> has been that for standard mixed workloads the overhead is minimal. The 
> throttling built in safely handles burst workloads.
> 
> James.
> 
> On Mon, 30 Sept 2024 at 14:22, Josh McKenzie  > wrote:
>>> This is the type of hidden subproject that will get us into trouble with 
>>> the board/foundation.   I'm sure it's getting enough committer eyeballs, 
>>> and some PMC oversight, but maybe not enough.
>> I don't agree with the qualifier of it as being hidden. It's definitely 
>> lower traffic than the main project but there's movement on the JIRA here: 
>> link 
>> .
>> 
>> I assume the sidecar is going to take longer to reach a tipping point where 
>> more people start contributing to it until it has compelling features 
>> that'll incentivize folks running their own bespoke sidecars to migrate over.
>> 
>> Agree with all your points Jon; there's a lot to be done on it.
>> 
>> CEP-1 is pretty much abandoned yeah. I think it'd be reasonable to close it 
>> down and open up a new one w/active contributors + active shepherd and a 
>> much more limited scope.
>> 
>> On Mon, Sep 30, 2024, at 2:13 PM, Patrick McFadin wrote:
>>> I'm mentioning it because I was surprised and I feel like I generally have 
>>> a finger on the pulse of the project.
>>> 
>>> I would love to talk about it more and get more community support and 
>>> interest.
>>> 
>>> On Mon, Sep 30, 2024 at 11:01 AM Mick Semb Wever >> > wrote:
>>> Agree with Jon, Josh and Patrick here.
>>> 
>>> This is the type of hidden subproject that will get us into trouble with 
>>> the board/foundation.   I'm sure it's getting enough committer eyeballs, 
>>> and some PMC oversight, but maybe not enough.  Addressing the more material 
>>> points that Jon mentions is the best way to deal with that IMHO.
>>> 
>>> 
>>> 
>>> On Mon, 30 Sept 2024 at 20:37, Jon Haddad >> > wrote:
>>> I think it depends on what lens you're looking at the sidecar through.
>>> 
>>> If you're actively working on it, and pulling it into your own infra, sure. 
>>>  It's a thing. 
>>> 
>>> If you're an outsider?  I have a hard time seeing it.
>>> 
>>> - No documentation as to what it does
>>> - No releases
>>> - No build instructions
>>> - Trying to build using standard gradle commands fails [1]
>>> - Included configs don't work out of the box. [2][3]
>>> - CEP-1 looks abandonded
>>> - The primary reason right now to use it looks to be analytics library, 
>>> which doesn't work for most teams due to lack of vnode support [4]
>>> 
>>> I think if you were to take a poll of 100 users outside this ML, I'd bet 
>>> almost every one would agree the sidecar isn't a thing yet, and that's 
>>> probably more important than if it's actually getting worked on.  I think 
>>> it has quite a ways to go before it looks to be more than an idea that's 
>>> incubating.
>>> 
>>> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120
>>> [2 https://issues.apache.org/jira/browse/CASSANDRASC-121
>>> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122
>>> [4] https://issues.apache.org/jira/browse/CASSANDRA-19594
>>> 
>>> 
>>> On Mon, Sep 30, 2024 at 11:14 AM Josh McKenzie >> > wrote:
>>> 
>>> The CEP for the sidecar has stalled. The sidecar itself is very much alive 
>>> and a thing.
>>> 
>>> CEP != artifact.
>>> 
>>> We should definitely clean that up though.
>>> 
>>> On Mon, Sep 30, 2024, at 10:59 AM, Dinesh Joshi wrote:
 Patrick, could you please elaborate? The Sidecar has been a thing for a 
 while now.
 
 On Mon, Sep 30, 2024 at 7:51 AM Patrick McFadin >>> > wrote:
 I made the mistake of asking two things in one email. 
 
 First thing I asked. Sidecar? Stalled CEP so why is this being talked 
 about like this is a thing?
 
 On Mon, Sep 30, 2024 at 7:21 AM Benedict >>> > wrot

Re: GoCQL module name change and next release

[João Reis]

I'm not sure if it's feasible to make a review/triage of all existing PRs
(77) and issues (158) a "requirement" for a 2.0 release. We definitely want
to look at the issues with the label "semver-major" at the very least. I'm
leaning towards not considering issues that don't require a breaking change
(except v5 support and vector support) for 2.0.0 as they can go into any
minor release afterwards but if there's an existing PR/issue that you'd
really like to see in 2.0.0 then you can bring them up here or tag me in
those specific PRs/issues.

Rolo, Carlos via dev  escreveu (segunda,
14/10/2024 à(s) 19:03):

> I agree that should be 1) and 2) together.
>
> Regarding the PR review for 2.0, I can look into some (I'm not proficient
> with Go, it has been a long time) but for triaging what should be in a
> major I can surely help. Low hanging fruit should also not be a problem for
> me to review.
>
> Are we looking to review/triaging all existing PRs?
>
> Thanks,
>
> Carlos
> --
> *From:* João Reis 
> *Sent:* 11 October 2024 16:03
> *To:* dev@cassandra.apache.org 
> *Subject:* Re: GoCQL module name change and next release
>
> You don't often get email from joaor...@apache.org. Learn why this is
> important 
> *EXTERNAL EMAIL - USE CAUTION when clicking links or attachments *
>
>
> I like that too, I initially considered proposing that but thought I'd
> propose delivering v5 and vector support faster but +1 on making these two
> features a part of 2.0.0 instead.
>
> Štefan Miklošovič  escreveu (quinta, 10/10/2024
> à(s) 23:37):
>
> I would do 1) and 2) together. I would rename the module in 2.0.0 and
> there would be v5 and vector support as well. It would motivate us to get
> v5 and vector out while using that opportunity to rename it to 2.0.0.
>
> On Thu, Oct 10, 2024 at 11:42 AM João Reis  wrote:
>
> Hi,
>
> Following the GoCQL donation we need to change the module name so it
> matches the new repo URL. Currently users have to keep using the old name
> unless they add a rewrite to go.mod.
>
> There was a discussion on what the approach should be on #1776 [1] and
> I've created CASSANDRA-19993 [2] to track this work. Since this is a
> breaking change (it requires users to modify their imports or add a rewrite
> to go.mod) we need to bump the major version when we do this.
>
> With this in mind, there's some topics to discuss:
>
> 1) When do we want to make this module name change happen? We can keep
> doing minor releases under the old module name but it is a bit confusing
> for new users to have to import gocql using a Github repo URL that
> effectively no longer exists. Also the amount of users that will be
> impacted by the module name change will only increase the longer we wait.
>
> 2) Should we take this opportunity to include other breaking change
> related issues with the module name change? Martin mentioned on the gocql
> mailing list [3] that there's a few issues on Github that are tagged with
> "semver-major" [4] and these should be considered for a new major release.
>
> My take on these topics is that we should work on some of those tagged
> issues when we decide to change the module name as long as these breaking
> changes don't require users to significantly rewrite parts of their
> application. We should make this upgrade and module name change to be the
> least intrusive as possible for users. Note that *the
> cassandra-gocql-driver project officially maintains the latest release*
> *only* (single active branch) so doing a major release effectively drops
> support for the previous major immediately which means we have an even
> stronger incentive to make the upgrade as easy as possible.
>
> I'm planning on reviewing protocol v5 and vector support PRs soon and we
> should probably make these 2 contributions available to users as soon as
> possible. To do this we can do a minor release before we start working on
> the next major. I'm also open to the idea that we could postpone the major
> release development and keep doing minor releases for a little longer under
> the old module name.
>
> In summary, my proposal for a short to medium term roadmap is:
>
> 1) Release 1.8.0 with v5 and vector support (and potentially other small
> PRs, I've only looked at these 2 issues yet)
> 2) Release 2.0.0 with the module name change, some (if not all) of the
> "semver-major" tagged issues and other contributions
>
> Let me know your thoughts,
> João Reis
>
> [1] https://github.com/apache/cassandra-gocql-driver/issues/1776
> [2] https://issues.apache.org/jira/browse/CASSANDRA-19993
> [3] https://groups.google.com/g/gocql/c/v0FruczBb2w/m/7Hc3_W9QCgAJ
> [4]
> https://github.com/apache/cassandra-gocql-driver/issues?q=is%3Aopen+is%3Aissue+label%3Asemver-major
>
>

Re: Status of CEP-1

[Patrick McFadin]

I have moved the original CEP-1 to the Archived section of Confluence:
https://cwiki.apache.org/confluence/x/gImzBQ

You can go ahead a create v2 of CEP-1 using the CEP template.

Patrick

On Tue, Oct 15, 2024 at 10:12 AM Josh McKenzie  wrote:

> Should make sure we snapshot it and/or history retention is sufficient for
> us to preserve the effort that went into the original. To Joey's point,
> there's a lot of hard work that went into it as it stands it'd be a shame
> to lose.
>
> On Tue, Oct 15, 2024, at 1:07 PM, Dinesh Joshi wrote:
>
> My preference would be to simply update CEP-1 instead of starting a new
> one. It achieves the same end goal and we can create new CEPs for the scope
> that is deferred.
>
> Dinesh
>
> On Mon, Oct 14, 2024 at 4:51 PM Patrick McFadin 
> wrote:
>
> I think that all sounds good. Let's get that new CEP started then. I think
> there are opinions flying around based on last week's discussions that need
> to coalesce.
>
> Patrick
>
> On Mon, Oct 14, 2024 at 3:19 PM Francisco Guerrero 
> wrote:
>
> From my point of view CEP-1 is overly broad in terms it wants to achieve.
> My understanding is that CEPs have to have a well-defined scope.
>
> I agree with Joey that we should close CEP-1 with the features I have
> proposed earlier in this thread. And have any future Sidecar work captured
> in
> subsequent CEPs.
>
> Best,
> - Francisco
>
> On 2024/10/14 21:58:55 Joseph Lynch wrote:
> > Hi everyone!
> >
> > I am curious what Dinesh's perspective is but I think the specific
> > enumerated scope in CEP-1 isn't super critical to be honest. That CEP
> > successfully (imo) built consensus that the community wants a separate
> > management process, and that sidecar both exists today and has useful
> > functionality (which is great!). I agree with Jon and others in these
> > threads that the functionality isn't super accessible until some of the
> > tickets Francisco mentioned are worked on and a release is made. I also
> > agree with Francisco that getting to a release, even if it is an alpha,
> > should be the goal - let's get to a release.
> >
> > I am personally fine closing CEP-1 and saying "This CEP has been
> superseded
> > by subsequent CEPs - future work in the sidecar requiring community
> > consensus will have separate CEPs as needed". That doesn't mean that the
> > scope in CEP-1 isn't useful, and I hope some of the gaps are added in the
> > future, but I think we can release without them and the focus should be
> on
> > the gaps for release not the gaps in functionality with CEP-1.
> >
> > Also I should mention I am extremely excited to see all the great
> features
> > that have landed and that there is a place outside the main DB for those
> > kinds of innovations to be tried out that doesn't conflict with the main
> > process. In my mind, having that place was the purpose of CEP-1, which is
> > done - the specific enumerated features are less important in my opinion.
> >
> > -Joey
> >
> > On Mon, Oct 14, 2024 at 4:09 PM Patrick McFadin 
> wrote:
> >
> > > What are we going to do with CEP-1? Cut and rescope in a new CEP or
> > > rewrite CEP-1?
> > >
> > > On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero <
> fran...@apache.org>
> > > wrote:
> > >
> > >> Hi folks,
> > >>
> > >> It was great meeting some of you in person at Community over Code
> where
> > >> we had a chance to discuss the Cassandra Sidecar project. A lot of
> > >> you expressed interest in having a release of Sidecar to start using
> the
> > >> existing features in the project:
> > >>
> > >> - C* adapters for versions 4.0, 4.1, 5.0 and trunk
> > >> - Cassandra Analytics support
> > >> - Restoring SSTables from S3-compatible object storage
> > >> - Mutual TLS authentication
> > >> - Role base access control
> > >> - Cluster health checks
> > >> - Observability
> > >> - Sidecar Client
> > >>
> > >> Some of the call-outs in this thread of things we need for a release:
> > >>
> > >> - Documentation
> > >> - Bug fixes [1][2][3]
> > >>
> > >> These are other things mentioned in the thread, where we would like
> help
> > >> from the community:
> > >>
> > >> - vNode support [4]
> > >> - Backup support [5]
> > >> - Bulk APIs [6]
> > >>
> > >> Once we have documentation and the bug fixes mentioned above, I will
> > >> start a thread vote for a release of Cassandra Sidecar 0.1 alpha.
> > >>
> > >> We want the community to benefit from the features already present in
> > >> Sidecar. The more community engagement we have, the more feature-rich
> > >> will become.
> > >>
> > >> Additionally, we can leverage easy-cass-stress to have Cassandra
> Sidecar
> > >> included in your Cassandra clusters, so we can easily start trying it
> out.
> > >>
> > >> Please let me know your thoughts on this.
> > >>
> > >> Best,
> > >> - Francisco
> > >>
> > >> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120
> > >> [2] https://issues.apache.org/jira/browse/CASSANDRASC-121
> > >> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122

Re: [DISCUSS] Donating easy-cass-stress to the project

[Josh McKenzie]

> IIUC there's no subproject involved here.
To elaborate a touch: this isn't a subproject in terms of governance. i.e. no 3 
dedicated PMC sponsors required, no "pmc must legally vote on releasing an 
artifact" (unless of course we start independently releasing artifacts for it 
as opposed to just pointing people at the repo and tags), and no real "we must 
have at least N people with a commit-bit and a focus on this area for it to be 
taken in".

Makes sense given the context and purpose of the tool and keeping it lighter 
weight should make it easier for everyone to collaborate on it, to Mick's point 
- much like the ccm and dtest repos.

On Tue, Oct 15, 2024, at 3:19 AM, Mick Semb Wever wrote:
> 
> IIUC there's no subproject involved here.  This is a separate repository 
> coming in, akin to cassandra-dtest (plus releases).
> 
> The question wrt replacing cassandra-stress was only thinking about something 
> down the road, to help smoke out stuff like compaction-stress.  No suggestion 
> implied that easy-cass-stress should be moved in-tree.
> 
> 
> 
> On Tue, 15 Oct 2024 at 00:15, David Capwell  wrote:
>>> I think we should just accept easy-cass-stress as a subproject and go
>>> from there.  Replacing stress can be handled separately and still has
>>> the large issue of reconciling the build systems that I raised in the
>>> beginning of this thread, but can be figured out eventually.
>> 
>> I strongly agree with you here. The proposal is to just add the project
>> 
>> 
>>> On Oct 14, 2024, at 11:08 AM, C. Scott Andreas  wrote:
>>> 
>>> Separating the two is completely fine yep -- just mentioned since 
>>> deprecation/removal of stress also came up in the thread.
>>> 
>>> Let's complete the donation. Just wanted to make sure we don't remove 
>>> compaction-stress without a substitute.
>>> 
>>> – Scott
>>> 
 On Oct 14, 2024, at 10:46 AM, Brandon Williams  wrote:
 
 
 I think we should just accept easy-cass-stress as a subproject and go
 from there. Replacing stress can be handled separately and still has
 the large issue of reconciling the build systems that I raised in the
 beginning of this thread, but can be figured out eventually.
 
 Kind Regards,
 Brandon
 
 On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad  
 wrote:
> 
> Scott, I think introducing replacing compaction stress as a requirement 
> here adds unnecessary friction to the donation process. I'd prefer to 
> avoid coupling the two things. Unless you or someone else is volunteering 
> to rewrite it I think this would effectively halt the donation, which I 
> doubt is your intention. Can we do that as a separate thing?
> 
> Regarding the name, I'm fine if we rename it. My tooling is easy-cass-*, 
> and renaming it would make it clear that it's no longer my project, 
> that's fine with me.
> 
> Jon
> 
> 
> On Sun, Oct 13, 2024 at 8:20 PM  wrote:
>> 
>> Supportive and would welcome the contribution as well. Jon, thanks for 
>> your willingness to offer this work to the Foundation.
>> 
>> Also supportive of considering easy-cass-stress the successor to 
>> cassandra-stress.
>> 
>> I’m fine with a directional goal of deprecating and removing 
>> cassandra-stress, but would like to make sure we have a successor to 
>> compaction-stress before doing so. I very rarely use cassandra-stress, 
>> but compaction-stress is helpful for generating a large corpus of 
>> SSTables and allowing compaction to churn through them. This is great 
>> for benching changes to the read path, compaction strategies, and for 
>> evaluation of hardware/VM/IO performance.
>> 
>> https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/CompactionStress.java
>> 
>> Apologies if this exists in easy-cass-stress today - I may have missed 
>> it. Our own documentation even lacks a mention of compaction-stress. :)
>> 
>> – Scott
>> 
>> On Oct 13, 2024, at 8:01 PM, Štefan Miklošovič  
>> wrote:
>> 
>> * easy-cass-stress, sorry. Everything else holds.
>> 
>> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič 
>>  wrote:
>>> 
>>> What does "replacing" actually mean? If this tool is added to a 
>>> separate repository, you mean like it would be put there under the 
>>> "easy-cass-lab" name and all source code of cassandra-stress in the 
>>> Cassandra repository would be removed? Are we going to deprecate what 
>>> we have first or it is going to be a big bang?
>>> 
>>> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not 
>>> think that "easy-cass-lab" should be the name of a repo we are going to 
>>> use. For a custom tool living outside of Cassandra until now, sure, but 
>>> the official stress tool should not be called "easy-cass-lab". People 
>>> would be like ... wh

Re: [DISCUSS] Donating easy-cass-stress to the project

[Mick Semb Wever]

IIUC there's no subproject involved here.  This is a separate repository
coming in, akin to cassandra-dtest (plus releases).

The question wrt replacing cassandra-stress was only thinking about
something down the road, to help smoke out stuff like compaction-stress.
No suggestion implied that easy-cass-stress should be moved in-tree.



On Tue, 15 Oct 2024 at 00:15, David Capwell  wrote:

> I think we should just accept easy-cass-stress as a subproject and go
> from there.  Replacing stress can be handled separately and still has
> the large issue of reconciling the build systems that I raised in the
> beginning of this thread, but can be figured out eventually.
>
>
> I strongly agree with you here. The proposal is to just add the project
>
>
> On Oct 14, 2024, at 11:08 AM, C. Scott Andreas 
> wrote:
>
> Separating the two is completely fine yep -- just mentioned since
> deprecation/removal of stress also came up in the thread.
>
> Let's complete the donation. Just wanted to make sure we don't remove
> compaction-stress without a substitute.
>
> – Scott
>
> On Oct 14, 2024, at 10:46 AM, Brandon Williams  wrote:
>
>
> I think we should just accept easy-cass-stress as a subproject and go
> from there. Replacing stress can be handled separately and still has
> the large issue of reconciling the build systems that I raised in the
> beginning of this thread, but can be figured out eventually.
>
> Kind Regards,
> Brandon
>
> On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad 
> wrote:
>
>
> Scott, I think introducing replacing compaction stress as a requirement
> here adds unnecessary friction to the donation process. I'd prefer to avoid
> coupling the two things. Unless you or someone else is volunteering to
> rewrite it I think this would effectively halt the donation, which I doubt
> is your intention. Can we do that as a separate thing?
>
> Regarding the name, I'm fine if we rename it. My tooling is easy-cass-*,
> and renaming it would make it clear that it's no longer my project, that's
> fine with me.
>
> Jon
>
>
> On Sun, Oct 13, 2024 at 8:20 PM  wrote:
>
>
> Supportive and would welcome the contribution as well. Jon, thanks for
> your willingness to offer this work to the Foundation.
>
> Also supportive of considering easy-cass-stress the successor to
> cassandra-stress.
>
> I’m fine with a directional goal of deprecating and removing
> cassandra-stress, but would like to make sure we have a successor to
> compaction-stress before doing so. I very rarely use cassandra-stress, but
> compaction-stress is helpful for generating a large corpus of SSTables and
> allowing compaction to churn through them. This is great for benching
> changes to the read path, compaction strategies, and for evaluation of
> hardware/VM/IO performance.
>
>
> https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/CompactionStress.java
>
> Apologies if this exists in easy-cass-stress today - I may have missed it.
> Our own documentation even lacks a mention of compaction-stress. :)
>
> – Scott
>
> On Oct 13, 2024, at 8:01 PM, Štefan Miklošovič 
> wrote:
>
> * easy-cass-stress, sorry. Everything else holds.
>
> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič 
> wrote:
>
>
> What does "replacing" actually mean? If this tool is added to a separate
> repository, you mean like it would be put there under the "easy-cass-lab"
> name and all source code of cassandra-stress in the Cassandra repository
> would be removed? Are we going to deprecate what we have first or it is
> going to be a big bang?
>
> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think
> that "easy-cass-lab" should be the name of a repo we are going to use. For
> a custom tool living outside of Cassandra until now, sure, but the official
> stress tool should not be called "easy-cass-lab". People would be like ...
> what? IMHO we should rename it to cassandra-stress.
>
> On Sun, Oct 13, 2024 at 8:33 PM Brad  wrote:
>
>
> I'm +1 on replacing the existing cassandra-stress. My team did some work
> last Summer to remove Thrift related CLI args, but arg parsing alone is a
> 5K line mess. It's certainly not being well-maintained and could use a
> replacement.
>
> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie 
> wrote:
>
>
> Unsolicited .02:
>
> - If this will eventually replace the in-tree cassandra-stress, does it
> warrant a CEP ? (i'm ok with skipping, though that step might have
> encouraged the questions above)
>
> I'm +1 to this replacing, -0 on requiring a CEP.
>
> Given the current tool is unmaintained and doesn't (to my knowledge) have
> a workflow-based usage paradigm that could be easily extended, seems like a
> clear win.
>
>
> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>
> reply below.
>
>
> I’m terms of next steps: Mick what do we need to do next? Figure out the
> answers to your questions re: getting contributor sign off?
>
>
>
> The process of donation is as follows… (feel free to correct me, or

Re: Status of CEP-1

[Dinesh Joshi]

My preference would be to simply update CEP-1 instead of starting a new
one. It achieves the same end goal and we can create new CEPs for the scope
that is deferred.

Dinesh

On Mon, Oct 14, 2024 at 4:51 PM Patrick McFadin  wrote:

> I think that all sounds good. Let's get that new CEP started then. I think
> there are opinions flying around based on last week's discussions that need
> to coalesce.
>
> Patrick
>
> On Mon, Oct 14, 2024 at 3:19 PM Francisco Guerrero 
> wrote:
>
>> From my point of view CEP-1 is overly broad in terms it wants to achieve.
>> My understanding is that CEPs have to have a well-defined scope.
>>
>> I agree with Joey that we should close CEP-1 with the features I have
>> proposed earlier in this thread. And have any future Sidecar work
>> captured in
>> subsequent CEPs.
>>
>> Best,
>> - Francisco
>>
>> On 2024/10/14 21:58:55 Joseph Lynch wrote:
>> > Hi everyone!
>> >
>> > I am curious what Dinesh's perspective is but I think the specific
>> > enumerated scope in CEP-1 isn't super critical to be honest. That CEP
>> > successfully (imo) built consensus that the community wants a separate
>> > management process, and that sidecar both exists today and has useful
>> > functionality (which is great!). I agree with Jon and others in these
>> > threads that the functionality isn't super accessible until some of the
>> > tickets Francisco mentioned are worked on and a release is made. I also
>> > agree with Francisco that getting to a release, even if it is an alpha,
>> > should be the goal - let's get to a release.
>> >
>> > I am personally fine closing CEP-1 and saying "This CEP has been
>> superseded
>> > by subsequent CEPs - future work in the sidecar requiring community
>> > consensus will have separate CEPs as needed". That doesn't mean that the
>> > scope in CEP-1 isn't useful, and I hope some of the gaps are added in
>> the
>> > future, but I think we can release without them and the focus should be
>> on
>> > the gaps for release not the gaps in functionality with CEP-1.
>> >
>> > Also I should mention I am extremely excited to see all the great
>> features
>> > that have landed and that there is a place outside the main DB for those
>> > kinds of innovations to be tried out that doesn't conflict with the main
>> > process. In my mind, having that place was the purpose of CEP-1, which
>> is
>> > done - the specific enumerated features are less important in my
>> opinion.
>> >
>> > -Joey
>> >
>> > On Mon, Oct 14, 2024 at 4:09 PM Patrick McFadin 
>> wrote:
>> >
>> > > What are we going to do with CEP-1? Cut and rescope in a new CEP or
>> > > rewrite CEP-1?
>> > >
>> > > On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero <
>> fran...@apache.org>
>> > > wrote:
>> > >
>> > >> Hi folks,
>> > >>
>> > >> It was great meeting some of you in person at Community over Code
>> where
>> > >> we had a chance to discuss the Cassandra Sidecar project. A lot of
>> > >> you expressed interest in having a release of Sidecar to start using
>> the
>> > >> existing features in the project:
>> > >>
>> > >> - C* adapters for versions 4.0, 4.1, 5.0 and trunk
>> > >> - Cassandra Analytics support
>> > >> - Restoring SSTables from S3-compatible object storage
>> > >> - Mutual TLS authentication
>> > >> - Role base access control
>> > >> - Cluster health checks
>> > >> - Observability
>> > >> - Sidecar Client
>> > >>
>> > >> Some of the call-outs in this thread of things we need for a release:
>> > >>
>> > >> - Documentation
>> > >> - Bug fixes [1][2][3]
>> > >>
>> > >> These are other things mentioned in the thread, where we would like
>> help
>> > >> from the community:
>> > >>
>> > >> - vNode support [4]
>> > >> - Backup support [5]
>> > >> - Bulk APIs [6]
>> > >>
>> > >> Once we have documentation and the bug fixes mentioned above, I will
>> > >> start a thread vote for a release of Cassandra Sidecar 0.1 alpha.
>> > >>
>> > >> We want the community to benefit from the features already present in
>> > >> Sidecar. The more community engagement we have, the more feature-rich
>> > >> will become.
>> > >>
>> > >> Additionally, we can leverage easy-cass-stress to have Cassandra
>> Sidecar
>> > >> included in your Cassandra clusters, so we can easily start trying
>> it out.
>> > >>
>> > >> Please let me know your thoughts on this.
>> > >>
>> > >> Best,
>> > >> - Francisco
>> > >>
>> > >> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120
>> > >> [2] https://issues.apache.org/jira/browse/CASSANDRASC-121
>> > >> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122
>> > >> [4] https://issues.apache.org/jira/browse/CASSANDRASC-149
>> > >> [5] https://issues.apache.org/jira/browse/CASSANDRASC-148
>> > >> [6] https://issues.apache.org/jira/browse/CASSANDRASC-3
>> > >>
>> > >> On 2024/10/03 12:05:14 Josh McKenzie wrote:
>> > >> > I'm tentatively in favor of the idea of us cutting releases for
>> all our
>> > >> ecosystem dependencies as a blocker to cutting a major with Cassandra
>> > >> proper. I say tent

Re: Status of CEP-1

[Francisco Guerrero]

That's a reasonable approach. I'm +1 with updating CEP-1 and closing it when
we release Sidecar.

On 2024/10/15 17:07:58 Dinesh Joshi wrote:
> My preference would be to simply update CEP-1 instead of starting a new
> one. It achieves the same end goal and we can create new CEPs for the scope
> that is deferred.
> 
> Dinesh
> 
> On Mon, Oct 14, 2024 at 4:51 PM Patrick McFadin  wrote:
> 
> > I think that all sounds good. Let's get that new CEP started then. I think
> > there are opinions flying around based on last week's discussions that need
> > to coalesce.
> >
> > Patrick
> >
> > On Mon, Oct 14, 2024 at 3:19 PM Francisco Guerrero 
> > wrote:
> >
> >> From my point of view CEP-1 is overly broad in terms it wants to achieve.
> >> My understanding is that CEPs have to have a well-defined scope.
> >>
> >> I agree with Joey that we should close CEP-1 with the features I have
> >> proposed earlier in this thread. And have any future Sidecar work
> >> captured in
> >> subsequent CEPs.
> >>
> >> Best,
> >> - Francisco
> >>
> >> On 2024/10/14 21:58:55 Joseph Lynch wrote:
> >> > Hi everyone!
> >> >
> >> > I am curious what Dinesh's perspective is but I think the specific
> >> > enumerated scope in CEP-1 isn't super critical to be honest. That CEP
> >> > successfully (imo) built consensus that the community wants a separate
> >> > management process, and that sidecar both exists today and has useful
> >> > functionality (which is great!). I agree with Jon and others in these
> >> > threads that the functionality isn't super accessible until some of the
> >> > tickets Francisco mentioned are worked on and a release is made. I also
> >> > agree with Francisco that getting to a release, even if it is an alpha,
> >> > should be the goal - let's get to a release.
> >> >
> >> > I am personally fine closing CEP-1 and saying "This CEP has been
> >> superseded
> >> > by subsequent CEPs - future work in the sidecar requiring community
> >> > consensus will have separate CEPs as needed". That doesn't mean that the
> >> > scope in CEP-1 isn't useful, and I hope some of the gaps are added in
> >> the
> >> > future, but I think we can release without them and the focus should be
> >> on
> >> > the gaps for release not the gaps in functionality with CEP-1.
> >> >
> >> > Also I should mention I am extremely excited to see all the great
> >> features
> >> > that have landed and that there is a place outside the main DB for those
> >> > kinds of innovations to be tried out that doesn't conflict with the main
> >> > process. In my mind, having that place was the purpose of CEP-1, which
> >> is
> >> > done - the specific enumerated features are less important in my
> >> opinion.
> >> >
> >> > -Joey
> >> >
> >> > On Mon, Oct 14, 2024 at 4:09 PM Patrick McFadin 
> >> wrote:
> >> >
> >> > > What are we going to do with CEP-1? Cut and rescope in a new CEP or
> >> > > rewrite CEP-1?
> >> > >
> >> > > On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero <
> >> fran...@apache.org>
> >> > > wrote:
> >> > >
> >> > >> Hi folks,
> >> > >>
> >> > >> It was great meeting some of you in person at Community over Code
> >> where
> >> > >> we had a chance to discuss the Cassandra Sidecar project. A lot of
> >> > >> you expressed interest in having a release of Sidecar to start using
> >> the
> >> > >> existing features in the project:
> >> > >>
> >> > >> - C* adapters for versions 4.0, 4.1, 5.0 and trunk
> >> > >> - Cassandra Analytics support
> >> > >> - Restoring SSTables from S3-compatible object storage
> >> > >> - Mutual TLS authentication
> >> > >> - Role base access control
> >> > >> - Cluster health checks
> >> > >> - Observability
> >> > >> - Sidecar Client
> >> > >>
> >> > >> Some of the call-outs in this thread of things we need for a release:
> >> > >>
> >> > >> - Documentation
> >> > >> - Bug fixes [1][2][3]
> >> > >>
> >> > >> These are other things mentioned in the thread, where we would like
> >> help
> >> > >> from the community:
> >> > >>
> >> > >> - vNode support [4]
> >> > >> - Backup support [5]
> >> > >> - Bulk APIs [6]
> >> > >>
> >> > >> Once we have documentation and the bug fixes mentioned above, I will
> >> > >> start a thread vote for a release of Cassandra Sidecar 0.1 alpha.
> >> > >>
> >> > >> We want the community to benefit from the features already present in
> >> > >> Sidecar. The more community engagement we have, the more feature-rich
> >> > >> will become.
> >> > >>
> >> > >> Additionally, we can leverage easy-cass-stress to have Cassandra
> >> Sidecar
> >> > >> included in your Cassandra clusters, so we can easily start trying
> >> it out.
> >> > >>
> >> > >> Please let me know your thoughts on this.
> >> > >>
> >> > >> Best,
> >> > >> - Francisco
> >> > >>
> >> > >> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120
> >> > >> [2] https://issues.apache.org/jira/browse/CASSANDRASC-121
> >> > >> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122
> >> > >> [4] https://issues.apache.org/jira/browse/CASSAN

Re: Status of CEP-1

[Josh McKenzie]

Should make sure we snapshot it and/or history retention is sufficient for us 
to preserve the effort that went into the original. To Joey's point, there's a 
lot of hard work that went into it as it stands it'd be a shame to lose.

On Tue, Oct 15, 2024, at 1:07 PM, Dinesh Joshi wrote:
> My preference would be to simply update CEP-1 instead of starting a new one. 
> It achieves the same end goal and we can create new CEPs for the scope that 
> is deferred.
> 
> Dinesh
> 
> On Mon, Oct 14, 2024 at 4:51 PM Patrick McFadin  wrote:
>> I think that all sounds good. Let's get that new CEP started then. I think 
>> there are opinions flying around based on last week's discussions that need 
>> to coalesce.
>> 
>> Patrick
>> 
>> On Mon, Oct 14, 2024 at 3:19 PM Francisco Guerrero  
>> wrote:
>>> From my point of view CEP-1 is overly broad in terms it wants to achieve.
>>> My understanding is that CEPs have to have a well-defined scope.
>>> 
>>> I agree with Joey that we should close CEP-1 with the features I have
>>> proposed earlier in this thread. And have any future Sidecar work captured 
>>> in
>>> subsequent CEPs.
>>> 
>>> Best,
>>> - Francisco
>>> 
>>> On 2024/10/14 21:58:55 Joseph Lynch wrote:
>>> > Hi everyone!
>>> > 
>>> > I am curious what Dinesh's perspective is but I think the specific
>>> > enumerated scope in CEP-1 isn't super critical to be honest. That CEP
>>> > successfully (imo) built consensus that the community wants a separate
>>> > management process, and that sidecar both exists today and has useful
>>> > functionality (which is great!). I agree with Jon and others in these
>>> > threads that the functionality isn't super accessible until some of the
>>> > tickets Francisco mentioned are worked on and a release is made. I also
>>> > agree with Francisco that getting to a release, even if it is an alpha,
>>> > should be the goal - let's get to a release.
>>> > 
>>> > I am personally fine closing CEP-1 and saying "This CEP has been 
>>> > superseded
>>> > by subsequent CEPs - future work in the sidecar requiring community
>>> > consensus will have separate CEPs as needed". That doesn't mean that the
>>> > scope in CEP-1 isn't useful, and I hope some of the gaps are added in the
>>> > future, but I think we can release without them and the focus should be on
>>> > the gaps for release not the gaps in functionality with CEP-1.
>>> > 
>>> > Also I should mention I am extremely excited to see all the great features
>>> > that have landed and that there is a place outside the main DB for those
>>> > kinds of innovations to be tried out that doesn't conflict with the main
>>> > process. In my mind, having that place was the purpose of CEP-1, which is
>>> > done - the specific enumerated features are less important in my opinion.
>>> > 
>>> > -Joey
>>> > 
>>> > On Mon, Oct 14, 2024 at 4:09 PM Patrick McFadin  
>>> > wrote:
>>> > 
>>> > > What are we going to do with CEP-1? Cut and rescope in a new CEP or
>>> > > rewrite CEP-1?
>>> > >
>>> > > On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero 
>>> > > wrote:
>>> > >
>>> > >> Hi folks,
>>> > >>
>>> > >> It was great meeting some of you in person at Community over Code where
>>> > >> we had a chance to discuss the Cassandra Sidecar project. A lot of
>>> > >> you expressed interest in having a release of Sidecar to start using 
>>> > >> the
>>> > >> existing features in the project:
>>> > >>
>>> > >> - C* adapters for versions 4.0, 4.1, 5.0 and trunk
>>> > >> - Cassandra Analytics support
>>> > >> - Restoring SSTables from S3-compatible object storage
>>> > >> - Mutual TLS authentication
>>> > >> - Role base access control
>>> > >> - Cluster health checks
>>> > >> - Observability
>>> > >> - Sidecar Client
>>> > >>
>>> > >> Some of the call-outs in this thread of things we need for a release:
>>> > >>
>>> > >> - Documentation
>>> > >> - Bug fixes [1][2][3]
>>> > >>
>>> > >> These are other things mentioned in the thread, where we would like 
>>> > >> help
>>> > >> from the community:
>>> > >>
>>> > >> - vNode support [4]
>>> > >> - Backup support [5]
>>> > >> - Bulk APIs [6]
>>> > >>
>>> > >> Once we have documentation and the bug fixes mentioned above, I will
>>> > >> start a thread vote for a release of Cassandra Sidecar 0.1 alpha.
>>> > >>
>>> > >> We want the community to benefit from the features already present in
>>> > >> Sidecar. The more community engagement we have, the more feature-rich
>>> > >> will become.
>>> > >>
>>> > >> Additionally, we can leverage easy-cass-stress to have Cassandra 
>>> > >> Sidecar
>>> > >> included in your Cassandra clusters, so we can easily start trying it 
>>> > >> out.
>>> > >>
>>> > >> Please let me know your thoughts on this.
>>> > >>
>>> > >> Best,
>>> > >> - Francisco
>>> > >>
>>> > >> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120
>>> > >> [2] https://issues.apache.org/jira/browse/CASSANDRASC-121
>>> > >> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122
>>> > >> [4] https://issues.apache.

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

Hi yifan,
Thanks for bringing this up. The SELECT permission on the original table is
needed. Mysql and PG all have mentioned this, and I also specifically
noticed this in my code.

I probably missed this in the cep documentation. 😅

Yifan Cai  于2024年10月16日周三 07:46写道：

> Thanks for creating the CEP! I think it is missing Bernardo's comment on
> "the need for read permissions on the source table".
>
> CreateTableStatement does not check the permissions outside of the
> enclosing keyspace. Having the SELECT permission on the original table is a
> requirement for CREATE TABLE LIKE.
>
> - Yifan
>
> On Sun, Sep 29, 2024 at 11:01 PM guo Maxwell  wrote:
>
>> Hello, everyone ,
>> I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
>> 
>>  as
>> said before, looking forward to your suggestions.
>>
>> Štefan Miklošovič  于2024年9月25日周三 03:51写道：
>>
>>> I am sorry I do not follow what you mean, maybe an example would help.
>>>
>>> On Tue, Sep 24, 2024 at 6:18 PM guo Maxwell 
>>> wrote:
>>>

 If there are multiple schema information changes in one ddl statement,
 will there be schema conflicts in extreme cases?
 For example, our statement contains both table creation and index
 creation.

 guo Maxwell 于2024年9月24日 周二下午8:12写道：

> +1 on splitting this task  and adding the ability to copy tables
> through different keyspaces in the future.
>
> Štefan Miklošovič  于2024年9月23日周一 22:05写道：
>
>> If we have this table
>>
>> CREATE TABLE ks.tb2 (
>> id int PRIMARY KEY,
>> name text
>> );
>>
>> I can either specify name of an index on my own like this:
>>
>> CREATE INDEX name_index ON ks.tb2 (name) ;
>>
>> or I can let Cassandra to figure that name on its own:
>>
>> CREATE INDEX ON ks.tb2 (name) ;
>>
>> in that case it will name that index "tb2_name_idx".
>>
>> Hence, I would expect that when we do
>>
>> ALTER TABLE ks.to_copy LIKE ks.tb2 WITH INDICES;
>>
>> Then ks.to_copy table will have an index which is called
>> "to_copy_name_idx" without me doing anything.
>>
>> For types, we do not need to do anything when we deal with the same
>> keyspace. For simplicity, I mentioned that we might deal with the same
>> keyspace scenario only for now and iterate on that in the future.
>>
>> On Mon, Sep 23, 2024 at 8:53 AM guo Maxwell 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> Cep is being written, and I encountered some problems during the
>>> process. I would like to discuss them with you. If you read the 
>>> description
>>> of this CASSANDRA-7662
>>> , we will
>>> find that initially the original creator of this jira did not intend to
>>> implement structural copying of indexes, views, and triggers  only the
>>> column and its data type.
>>>
>>> However, after investigating some db related syntax and function
>>> implementation, I found that it may be necessary for us to provide some
>>> rich syntax to support the replication of indexes, views, etc.
>>>
>>> In order to support selective copy of the basic structure of the
>>> table (columns and types), table options, table-related indexes, views,
>>> triggers, etc. We need some new syntax, it seems that the syntax of pg 
>>> is
>>> relatively comprehensive, it use the keyword INCLUDING/EXCLUDING to
>>> flexibly control the removal and retention of indexes, table 
>>> information,
>>> etc. see pg create table like
>>>  , the
>>> new created index name is different from the original table's index 
>>> name ,
>>> seenewly copied index names are different from original
>>> 
>>> , the name is based on some rule.
>>> Mysql is relatively simple and copies columns and indexes by
>>> default. see mysql create table like
>>> 
>>> and the newly created index name is the same with the original table's
>>> index name.
>>>
>>> So for Casandra, I hope it can also support the information copy of
>>> index and even view/trigger. And I also hope to be able to flexibly 
>>> decide
>>> which information is copied like pg.
>>>
>>> Besides, I think the copy can happen between different keyspaces.
>>> And UDT needs to be taken into account.
>>>
>>> But as we know the index/view/trigger name are all under keyspace
>>> level, so it seems that the newly created index name (or view name/ 
>>> trigger
>>> name) must be different from the original tables' ,otherwise  names 
>>> would
>

Re: [VOTE] CEP-43: Apache Cassandra CREATE TABLE LIKE

[Yifan Cai]

For further discussions, should we use the discussion thread? This thread
is for voting.

- Yifan

On Tue, Oct 15, 2024 at 3:31 PM Bernardo Botella <
conta...@bernardobotella.com> wrote:

> Hi Guo,
>
> Do you think it would make sense to add a fourth keyword to add after the
> WITH for Constraints? (See CEP-42)
>
> Copying a table without the defined constraints may be useful.
>
> Bernardo
>
>
> On Oct 9, 2024, at 9:32 PM, guo Maxwell  wrote:
>
> ok, I think the time can be two weeks .
>
> Looking forward to your feedback.
>
> Abe Ratnofsky  于2024年10月10日周四 11:51写道：
>
>> With the CEP only being completed last week and the Community over Code
>> conference finishing up this week, I'd love to have a few more days to
>> review and discuss the proposal.
>
>
>

Re: [VOTE] CEP-43: Apache Cassandra CREATE TABLE LIKE

[Bernardo Botella]

Fair point. I will move my feedback there.

> On Oct 15, 2024, at 4:19 PM, Yifan Cai  wrote:
> 
> For further discussions, should we use the discussion thread? This thread is 
> for voting. 
> 
> - Yifan
> 
> On Tue, Oct 15, 2024 at 3:31 PM Bernardo Botella 
> mailto:conta...@bernardobotella.com>> wrote:
>> Hi Guo,
>> 
>> Do you think it would make sense to add a fourth keyword to add after the 
>> WITH for Constraints? (See CEP-42)
>> 
>> Copying a table without the defined constraints may be useful.
>> 
>> Bernardo
>> 
>> 
>>> On Oct 9, 2024, at 9:32 PM, guo Maxwell >> > wrote:
>>> 
>>> ok, I think the time can be two weeks . 
>>> 
>>> Looking forward to your feedback.
>>> 
>>> Abe Ratnofsky mailto:a...@aber.io>> 于2024年10月10日周四 11:51写道：
 With the CEP only being completed last week and the Community over Code 
 conference finishing up this week, I'd love to have a few more days to 
 review and discuss the proposal.
>> 

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Bernardo Botella]

Hi Guo,

Do you think it would make sense to add a fourth keyword to add after the WITH 
for Constraints? (See CEP-42)

Copying a table without the defined constraints may be useful.

Bernardo

> On Sep 29, 2024, at 11:00 PM, guo Maxwell  wrote:
> 
> Hello, everyone , 
> I have finished the doc for CEP-43 for CREATE_TABLE_LIKE 
> 
>  as said before, looking forward to your suggestions. 
> 
> Štefan Miklošovič mailto:smikloso...@apache.org>> 
> 于2024年9月25日周三 03:51写道：
>> I am sorry I do not follow what you mean, maybe an example would help.
>> 
>> On Tue, Sep 24, 2024 at 6:18 PM guo Maxwell > > wrote:
>>> 
>>> If there are multiple schema information changes in one ddl statement, will 
>>> there be schema conflicts in extreme cases?
>>> For example, our statement contains both table creation and index creation.
>>> 
>>> guo Maxwell mailto:cclive1...@gmail.com>>于2024年9月24日 
>>> 周二下午8:12写道：
 +1 on splitting this task  and adding the ability to copy tables through 
 different keyspaces in the future. 
 
 Štefan Miklošovič mailto:smikloso...@apache.org>> 
 于2024年9月23日周一 22:05写道：
> If we have this table
> 
> CREATE TABLE ks.tb2 (
> id int PRIMARY KEY,
> name text
> );
> 
> I can either specify name of an index on my own like this:
> 
> CREATE INDEX name_index ON ks.tb2 (name) ;
> 
> or I can let Cassandra to figure that name on its own:
> 
> CREATE INDEX ON ks.tb2 (name) ;
> 
> in that case it will name that index "tb2_name_idx".
> 
> Hence, I would expect that when we do
> 
> ALTER TABLE ks.to_copy LIKE ks.tb2 WITH INDICES;
> 
> Then ks.to_copy table will have an index which is called 
> "to_copy_name_idx" without me doing anything.
> 
> For types, we do not need to do anything when we deal with the same 
> keyspace. For simplicity, I mentioned that we might deal with the same 
> keyspace scenario only for now and iterate on that in the future. 
> 
> On Mon, Sep 23, 2024 at 8:53 AM guo Maxwell  > wrote:
>> Hello everyone, 
>> 
>> Cep is being written, and I encountered some problems during the 
>> process. I would like to discuss them with you. If you read the 
>> description of this CASSANDRA-7662 
>> , we will find 
>> that initially the original creator of this jira did not intend to 
>> implement structural copying of indexes, views, and triggers  only the 
>> column and its data type.
>> 
>> However, after investigating some db related syntax and function 
>> implementation, I found that it may be necessary for us to provide some 
>> rich syntax to support the replication of indexes, views, etc.
>> 
>> In order to support selective copy of the basic structure of the table 
>> (columns and types), table options, table-related indexes, views, 
>> triggers, etc. We need some new syntax, it seems that the syntax of pg 
>> is relatively comprehensive, it use the keyword INCLUDING/EXCLUDING to 
>> flexibly control the removal and retention of indexes, table 
>> information, etc. see pg create table like 
>>  , the new 
>> created index name is different from the original table's index name , 
>> seenewly copied index names are different from original 
>> 
>>  , the name is based on some rule. 
>> Mysql is relatively simple and copies columns and indexes by default. 
>> see mysql create table like 
>>  and the 
>> newly created index name is the same with the original table's index 
>> name.
>> 
>> So for Casandra, I hope it can also support the information copy of 
>> index and even view/trigger. And I also hope to be able to flexibly 
>> decide which information is copied like pg.
>> 
>> Besides, I think the copy can happen between different keyspaces. And 
>> UDT needs to be taken into account.
>> 
>> But as we know the index/view/trigger name are all under keyspace level, 
>> so it seems that the newly created index name (or view name/ trigger 
>> name) must be different from the original tables' ,otherwise  names 
>> would clash .
>> 
>> So regarding the above problem, one idea I have is that for newly 
>> created types, indexes and views under different keyspaces and the same 
>> keyspace, we first generate random names for them, and then we can add 
>> the ability of modifying the names(for types/indexes/views/triggers) so 
>> that users can manually change t

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Yifan Cai]

Thanks for creating the CEP! I think it is missing Bernardo's comment on
"the need for read permissions on the source table".

CreateTableStatement does not check the permissions outside of the
enclosing keyspace. Having the SELECT permission on the original table is a
requirement for CREATE TABLE LIKE.

- Yifan

On Sun, Sep 29, 2024 at 11:01 PM guo Maxwell  wrote:

> Hello, everyone ,
> I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
> 
>  as
> said before, looking forward to your suggestions.
>
> Štefan Miklošovič  于2024年9月25日周三 03:51写道：
>
>> I am sorry I do not follow what you mean, maybe an example would help.
>>
>> On Tue, Sep 24, 2024 at 6:18 PM guo Maxwell  wrote:
>>
>>>
>>> If there are multiple schema information changes in one ddl statement,
>>> will there be schema conflicts in extreme cases?
>>> For example, our statement contains both table creation and index
>>> creation.
>>>
>>> guo Maxwell 于2024年9月24日 周二下午8:12写道：
>>>
 +1 on splitting this task  and adding the ability to copy tables
 through different keyspaces in the future.

 Štefan Miklošovič  于2024年9月23日周一 22:05写道：

> If we have this table
>
> CREATE TABLE ks.tb2 (
> id int PRIMARY KEY,
> name text
> );
>
> I can either specify name of an index on my own like this:
>
> CREATE INDEX name_index ON ks.tb2 (name) ;
>
> or I can let Cassandra to figure that name on its own:
>
> CREATE INDEX ON ks.tb2 (name) ;
>
> in that case it will name that index "tb2_name_idx".
>
> Hence, I would expect that when we do
>
> ALTER TABLE ks.to_copy LIKE ks.tb2 WITH INDICES;
>
> Then ks.to_copy table will have an index which is called
> "to_copy_name_idx" without me doing anything.
>
> For types, we do not need to do anything when we deal with the same
> keyspace. For simplicity, I mentioned that we might deal with the same
> keyspace scenario only for now and iterate on that in the future.
>
> On Mon, Sep 23, 2024 at 8:53 AM guo Maxwell 
> wrote:
>
>> Hello everyone,
>>
>> Cep is being written, and I encountered some problems during the
>> process. I would like to discuss them with you. If you read the 
>> description
>> of this CASSANDRA-7662
>> , we will find
>> that initially the original creator of this jira did not intend to
>> implement structural copying of indexes, views, and triggers  only the
>> column and its data type.
>>
>> However, after investigating some db related syntax and function
>> implementation, I found that it may be necessary for us to provide some
>> rich syntax to support the replication of indexes, views, etc.
>>
>> In order to support selective copy of the basic structure of the
>> table (columns and types), table options, table-related indexes, views,
>> triggers, etc. We need some new syntax, it seems that the syntax of pg is
>> relatively comprehensive, it use the keyword INCLUDING/EXCLUDING to
>> flexibly control the removal and retention of indexes, table information,
>> etc. see pg create table like
>>  , the new
>> created index name is different from the original table's index name , 
>> seenewly
>> copied index names are different from original
>> 
>> , the name is based on some rule.
>> Mysql is relatively simple and copies columns and indexes by default.
>> see mysql create table like
>>  and
>> the newly created index name is the same with the original table's index
>> name.
>>
>> So for Casandra, I hope it can also support the information copy of
>> index and even view/trigger. And I also hope to be able to flexibly 
>> decide
>> which information is copied like pg.
>>
>> Besides, I think the copy can happen between different keyspaces. And
>> UDT needs to be taken into account.
>>
>> But as we know the index/view/trigger name are all under keyspace
>> level, so it seems that the newly created index name (or view name/ 
>> trigger
>> name) must be different from the original tables' ,otherwise  names would
>> clash .
>>
>> So regarding the above problem, one idea I have is that for newly
>> created types, indexes and views under different keyspaces and the same
>> keyspace, we first generate random names for them, and then we can add 
>> the
>> ability of modifying the names(for types/indexes/views/triggers) so that
>> users can manually change the names.
>>
>>
>> guo Maxwell  于20

Re: [VOTE] CEP-43: Apache Cassandra CREATE TABLE LIKE

[Bernardo Botella]

Hi Guo,

Do you think it would make sense to add a fourth keyword to add after the WITH 
for Constraints? (See CEP-42)

Copying a table without the defined constraints may be useful.

Bernardo


> On Oct 9, 2024, at 9:32 PM, guo Maxwell  wrote:
> 
> ok, I think the time can be two weeks . 
> 
> Looking forward to your feedback.
> 
> Abe Ratnofsky mailto:a...@aber.io>> 于2024年10月10日周四 11:51写道：
>> With the CEP only being completed last week and the Community over Code 
>> conference finishing up this week, I'd love to have a few more days to 
>> review and discuss the proposal.