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

[guo Maxwell]

Thank you everyone. If there is no other feedback, I feel that this vote
has passed and CEP-43 is adopted.

Bernardo Botella  于2024年11月6日周三 23:40写道：

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

[Štefan Miklošovič]

Hi Maxwell,

any CEP in general requires more binding votes than 1 from myself.

I advise you to wait a little bit longer until at least three binding votes
accumulate.

Regards

On Thu, Nov 7, 2024 at 4:42 PM guo Maxwell  wrote:

> Thank you everyone. If there is no other feedback, I feel that this vote
> has passed and CEP-43 is adopted.
>
> Bernardo Botella  于2024年11月6日周三 23:40写道：
>
>> +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 <
 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.
>
>
>

>>

[DISCUSS] GoCQL sub modules vs packages

[João Reis]

The goal of CASSGO-21 [1] is to move HostPoolHostPolicy out of the main
package so that users don't have to download the
github.com/hailocab/go-hostpool dependency if they are not using this
specific policy.
The question is whether we want to move this policy to a separate module or
if it is enough to move it to a separate package on the same module. There
is currently an open PR for this issue that uses the separate package
approach [2].

The way we choose to resolve CASSGO-21 should dictate what we do in the
future for similar "extension" like code. For example, the PR [4] for
CASSGO-9 [3] adds 2 "extensions" that provide out of the box functionality
to use the logging libraries "zap" and "zerolog" with gocql and these are
implemented in their own independent modules that are located in an
"extensions" folder of gocql's repository.

Lz4 support is also implemented as an independent module at the moment and
as part of CASSGO-1 (protocol v5 support) we need to run the integration
test suite with lz4 compression since snappy is not supported in protocol
v5 but this creates a circular dependency between "gocql/go.mod" and
"gocql/lz4/go.mod". For context, CI only uses snappy compression on
integration tests at the moment. The circular dependency might be ok since
its usage in the "gocql" package is limited to "_test.go" files, but it
doesn't look great.

In summary, I think we should either move HostPoolHostPolicy to a new
module or we should consider making "gocql/lz4" a package instead of a
module and changing CASSGO-9's patch so that zap and zerolog support is
also implemented in separate packages instead of modules.

In my opinion we should use packages within the main "gocql" module for
this instead of separate modules (at the very least for
"HostPoolHostPolicy" and "lz4"). Separate modules could make sense when we
want to independently version and release a particular "extension" but in
my opinion I don't think we have that requirement for the specific use
cases that I've mentioned so far.

[1] https://issues.apache.org/jira/browse/CASSGO-21
[2] https://github.com/apache/cassandra-gocql-driver/pull/1770
[3] https://issues.apache.org/jira/browse/CASSGO-9
[4] https://github.com/apache/cassandra-gocql-driver/pull/1755
[5] https://issues.apache.org/jira/browse/CASSGO-1

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

[Dinesh Joshi]

Maxwell, here's the documentation for project governance for reference -
https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance

Like Stefan said, please wait until more binding +1s come in.

I'm +1 on the CEP.

thanks,

Dinesh


On Thu, Nov 7, 2024 at 7:51 AM Štefan Miklošovič 
wrote:

> Hi Maxwell,
>
> any CEP in general requires more binding votes than 1 from myself.
>
> I advise you to wait a little bit longer until at least three binding
> votes accumulate.
>
> Regards
>
> On Thu, Nov 7, 2024 at 4:42 PM guo Maxwell  wrote:
>
>> Thank you everyone. If there is no other feedback, I feel that this vote
>> has passed and CEP-43 is adopted.
>>
>> Bernardo Botella  于2024年11月6日周三 23:40写道：
>>
>>> +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 <
> 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.
>>
>>
>>
>
>>>

[DISCUSS] Go version in go.mod (GoCQL)

[João Reis]

The Go version that is specified in "go.mod" is 1.13 but this is out of
date, 1.17 is required to build GoCQL at the moment. Bumping the version on
this file to 1.17 needs to be done regardless but should we bump this
version to the minimum Go version that GoCQL officially supports or the one
that is actually required to build? For context, GoCQL officially supports
the latest 2 Go releases (currently 1.22 and 1.23) and these versions are
what we use in CI.

This topic was brought up while reviewing the PR [1] for CASSGO-1 (v5
support) [2] because a reference to "atomic.Bool" was added which requires
Go 1.19.

Personally I don't think we have to bump the version on go.mod to a version
that we test against in CI but bumping it to 1.19 seems reasonable to me.

Bumping the version on go.mod to a version that we use in CI would allow us
to use new Go features sooner but it would also require every user to
upgrade the Go version on their application.

[1] https://github.com/apache/cassandra-gocql-driver/pull/1822
[2] https://issues.apache.org/jira/browse/CASSGO-1

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

[guo Maxwell]

Thanks Stefan and Dinesh. Let's wait a little longer.


Dinesh Joshi  于2024年11月7日周四 23:56写道：

> Maxwell, here's the documentation for project governance for reference -
> https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance
>
> Like Stefan said, please wait until more binding +1s come in.
>
> I'm +1 on the CEP.
>
> thanks,
>
> Dinesh
>
>
> On Thu, Nov 7, 2024 at 7:51 AM Štefan Miklošovič 
> wrote:
>
>> Hi Maxwell,
>>
>> any CEP in general requires more binding votes than 1 from myself.
>>
>> I advise you to wait a little bit longer until at least three binding
>> votes accumulate.
>>
>> Regards
>>
>> On Thu, Nov 7, 2024 at 4:42 PM guo Maxwell  wrote:
>>
>>> Thank you everyone. If there is no other feedback, I feel that this vote
>>> has passed and CEP-43 is adopted.
>>>
>>> Bernardo Botella  于2024年11月6日周三 23:40写道：
>>>
 +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 <
>> 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: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Dave Herrington]

I wanted to weigh in on the options handling.

Being able to override table options like compaction strategy would be
valuable for use cases when we are evaluating side-by-side the performance
of different compaction settings.

We can always do ALTER TABLE after the CREATE TABLE LIKE, but it would be
slicker if we could do it in a single step.

Not the end of the world if this capability isn't provided, but it would be
a convenient feature to have sometime in the future.

Also, in the CEP, I see "[ WITH OPTIONS..." in the CQL Parser.g definition,
but I can't figure out what it means.

-Dave

On Wed, Nov 6, 2024 at 4:10 AM Štefan Miklošovič 
wrote:

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

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Dave Herrington]

👍

On Thu, Nov 7, 2024 at 10:58 PM guo Maxwell  wrote:

> Thank you very much for your careful observation. I have corrected it, it
> is out of date, just remove the OPTIONS keyword.
>
>
> Dave Herrington  于2024年11月8日周五 14:52写道：
>
>> I wanted to weigh in on the options handling.
>>
>> Being able to override table options like compaction strategy would be
>> valuable for use cases when we are evaluating side-by-side the performance
>> of different compaction settings.
>>
>> We can always do ALTER TABLE after the CREATE TABLE LIKE, but it would be
>> slicker if we could do it in a single step.
>>
>> Not the end of the world if this capability isn't provided, but it would
>> be a convenient feature to have sometime in the future.
>>
>> Also, in the CEP, I see "[ WITH OPTIONS..." in the CQL Parser.g
>> definition, but I can't figure out what it means.
>>
>> -Dave
>>
>> On Wed, Nov 6, 2024 at 4:10 AM Štefan Miklošovič 
>> wrote:
>>
>>> 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

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

Thank you very much for your careful observation. I have corrected it, it
is out of date, just remove the OPTIONS keyword.


Dave Herrington  于2024年11月8日周五 14:52写道：

> I wanted to weigh in on the options handling.
>
> Being able to override table options like compaction strategy would be
> valuable for use cases when we are evaluating side-by-side the performance
> of different compaction settings.
>
> We can always do ALTER TABLE after the CREATE TABLE LIKE, but it would be
> slicker if we could do it in a single step.
>
> Not the end of the world if this capability isn't provided, but it would
> be a convenient feature to have sometime in the future.
>
> Also, in the CEP, I see "[ WITH OPTIONS..." in the CQL Parser.g
> definition, but I can't figure out what it means.
>
> -Dave
>
> On Wed, Nov 6, 2024 at 4:10 AM Štefan Miklošovič 
> wrote:
>
>> 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 TABL