Re: [VOTE] CEP-37: Repair scheduling inside C*

[Chris Lohfink]

+1

On Wed, Nov 6, 2024 at 11:10 AM Francisco Guerrero 
wrote:

> +1 (nb)
>
> On 2024/11/06 14:07:47 "Tolbert, Andy" wrote:
> > +1 (nb)
> >
> > On Tue, Nov 5, 2024 at 9:51 PM Josh McKenzie 
> wrote:
> >
> > > +1
> > >
> > > On Tue, Nov 5, 2024, at 4:28 PM, Jaydeep Chovatia wrote:
> > >
> > > Hi Everyone,
> > >
> > > I would like to start the voting for CEP-37 as all the feedback in the
> > > discussion thread seems to be addressed.
> > >
> > > Proposal: CEP-37 Repair Scheduling Inside Cassandra
> > > <
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-37+Apache+Cassandra+Unified+Repair+Solution
> >
> > > Discussion thread:
> > > https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln
> > >
> > > As per the CEP process documentation, this vote will be open for 72
> hours
> > > (longer if needed).
> > >
> > > Thanks,
> > > Jaydeep
> > >
> > >
> >
>

Re: [VOTE] CEP-37: Repair scheduling inside C*

[Francisco Guerrero]

+1 (nb)

On 2024/11/06 14:07:47 "Tolbert, Andy" wrote:
> +1 (nb)
> 
> On Tue, Nov 5, 2024 at 9:51 PM Josh McKenzie  wrote:
> 
> > +1
> >
> > On Tue, Nov 5, 2024, at 4:28 PM, Jaydeep Chovatia wrote:
> >
> > Hi Everyone,
> >
> > I would like to start the voting for CEP-37 as all the feedback in the
> > discussion thread seems to be addressed.
> >
> > Proposal: CEP-37 Repair Scheduling Inside Cassandra
> > 
> > Discussion thread:
> > https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln
> >
> > As per the CEP process documentation, this vote will be open for 72 hours
> > (longer if needed).
> >
> > Thanks,
> > Jaydeep
> >
> >
> 

Re: [VOTE] CEP-37: Repair scheduling inside C*

[Tolbert, Andy]

+1 (nb)

On Tue, Nov 5, 2024 at 9:51 PM Josh McKenzie  wrote:

> +1
>
> On Tue, Nov 5, 2024, at 4:28 PM, Jaydeep Chovatia wrote:
>
> Hi Everyone,
>
> I would like to start the voting for CEP-37 as all the feedback in the
> discussion thread seems to be addressed.
>
> Proposal: CEP-37 Repair Scheduling Inside Cassandra
> 
> Discussion thread:
> https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln
>
> As per the CEP process documentation, this vote will be open for 72 hours
> (longer if needed).
>
> Thanks,
> Jaydeep
>
>

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Štefan Miklošovič]

Alright ... So, it is OK to NOT support this:

CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
WITH TRIGGERS
AND VIEWS
AND compaction = { 'class' : 'LeveledCompactionStrategy' }
AND default_time_to_live = 86400;

I think that if we ever wanted to support overriding of table options, we
_could_ deliver it later on if there is enough demand. From a syntax /
grammar point of view, being able to override these options is just a pure
addition to that syntax. Everything stays, we would just expand this. Hence
from the user's perspective it would be just an extension of this whole
feature.

Supporting the 5 examples is OK. It is crucial that the options of a table
we are making copy of are carried over to a new table as well.



On Wed, Nov 6, 2024 at 7:17 AM guo Maxwell  wrote:

> Any update on this ?If there are no updates, I wonder if we can start a
> new update on the VOTE thread.
>
> guo Maxwell  于2024年11月5日周二 19:23写道：
>
>> Hello, everyone.
>> I have a point of view that our CREATE TABLE LIKE grammar should not
>> support the setting of table options, like :
>>
>>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name WITH
>>> TRIGGERS AND VIEWS AND compaction = { 'class' : 'LeveledCompactionStrategy'
>>> } AND default_time_to_live = 86400;
>>
>> If the user wants to copy the table and set the compaction strategy for
>> the new table, then he can execute the
>> ALTER TABLE statement after copying the table.
>>
>> So, I think it’s enough to support the above five cases . The original
>> intention of copying a table is to copy the table,
>> and support what is to or not to copy during the copying process. Not
>> changing the options at the same time.
>>
>> WDYT ?
>>
>> guo Maxwell  于2024年11月5日周二 14:07写道：
>>
>>> Hi，stefan and Dave,
>>> I do not intend to implement the BNF of COPY TABLE based on the BNF of
>>> CREATE TABLE. All table options are indeed copied by default. Therefore,
>>> the following syntax is not supported:
>>>
>>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name WITH
 TRIGGERS AND VIEWS AND compaction = { 'class' : 'LeveledCompactionStrategy'
 } AND default_time_to_live = 86400;
>>>
>>>
>>> We can see that the above statement itself is very complicated because
>>> it provides too many choices.
>>> If we support individual settings of table options
>>> (compaction/compression), what about other TRIGGER/INDEXS ? I tend to treat
>>> the table, TRIGGER, INDEX, etc. as a whole and copy them uniformly. As for
>>> their own attributes, such as table options, INDEX attributes, etc., they
>>> can be copied and then set manually.
>>>
>>> So we only going to support :
>>>
 1.CREATE TABLE newks.newtable LIKE oldks.oldtable
 2.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH ALL // this
 means copy indexes and triggers
 3.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH INDEXES
 4.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH TRIGGERS
 5.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH TRIGGERS AND
 INDEXES // equal to option 2.
>>>
>>>
>>> Štefan Miklošovič  于2024年11月4日周一 23:31写道：
>>>
 1) Just mention that it will not be part of phase 1, I am OK if it will
 be delivered later.

 2) If we had "ALL" introduced, then we would have something like this:

 CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
 WITH
 ALL
 AND compaction = { 'class' : 'LeveledCompactionStrategy' }
 AND default_time_to_live = 86400;

 I think this is a little bit "strange". It would make sense to add ALL
 if we have not had any "AND"s but mixing ALL and then adding AND with
 options is a little bit confusing.

 3)

 Do I understand correctly that your CEP will make this possible? I do
 not want to go into the implementation details for now.

 CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
 WITH TRIGGERS
 AND VIEWS
 AND compaction = { 'class' : 'LeveledCompactionStrategy' }
 AND default_time_to_live = 86400;

 In other words, it will copy all options from "cycling.cyclist_name"
 while it will be possible to override the options with whatever I want?
 Basically what Dave suggested.


 On Mon, Nov 4, 2024 at 4:21 PM guo Maxwell 
 wrote:

> Hi stefan
> 1、yes, cross-keyspace copying will be much complicated than copying
> under same keyspace , but I think we can support it in the future , and I
> think it is under the scope of this CEP , so I add it .Or is it that the
> work planned for the next step should not be listed here for the time
> being?
> I don't know the rules very well here, and I hope if you can help
> point out the unreasonable points 😀 , because I do plan to complete
> this task, although I have only implemented the same keyspace now.
> 2、yes, you are right, I gave up ALL at the first time , But

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

[Bernardo Botella]

+1 (nb)

Thanks a lot Guo for addressing all the comments!

> On Nov 6, 2024, at 7:21 AM, Štefan Miklošovič  wrote:
> 
> Having all cleared out in discussion thread (1), I think we can finally vote 
> on this.
> 
> +1
> 
> I welcome everybody to finish this vote or raise other issues in the 
> discussion thread if any.
> 
> (1) https://lists.apache.org/thread/2z09twbrv75rszpxbm1przxxohpjvkkl
> 
> On Mon, Nov 4, 2024 at 2:53 AM guo Maxwell  > wrote:
>> Now at this point I think we can continue  the voting for CEP-43 as all the 
>> feedback in the discussion thread seems to be addressed.
>> 
>> Proposal: CEP43-CREATE TABLE LIKE 
>> 
>> Discussion thread:  discussion 
>> 
>> 
>> As per the CEP process documentation, this vote will be open for 72 hours 
>> (longer if needed).
>> 
>> Bernardo Botella > > 于2024年10月16日周三 07:40写道：
>>> 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: [VOTE] CEP-43: Apache Cassandra CREATE TABLE LIKE

[Štefan Miklošovič]

Having all cleared out in discussion thread (1), I think we can finally
vote on this.

+1

I welcome everybody to finish this vote or raise other issues in the
discussion thread if any.

(1) https://lists.apache.org/thread/2z09twbrv75rszpxbm1przxxohpjvkkl

On Mon, Nov 4, 2024 at 2:53 AM guo Maxwell  wrote:

> Now at this point I think we can continue  the voting for CEP-43 as all
> the feedback in the discussion thread seems to be addressed.
>
> Proposal: CEP43-CREATE TABLE LIKE
> 
> Discussion thread:  discussion
> 
>
> As per the CEP process documentation, this vote will be open for 72 hours
> (longer if needed).
>
> Bernardo Botella  于2024年10月16日周三 07:40写道：
>
>> 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 <
>> 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.
>>>
>>>
>>>
>>