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 <cclive1...@gmail.com> 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 <cclive1...@gmail.com> 于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 <cclive1...@gmail.com> 于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č <smikloso...@apache.org> 于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 <cclive1...@gmail.com>
>>>> 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 after I
>>>>> replied to yifan’s email, I communicated with him privately through slack.
>>>>> In the end, I was not strongly opposed to ALL (Sorry, we communicated in
>>>>> Chinese,
>>>>> https://the-asf.slack.com/archives/D07SXB787HN/p1729136909357689), In
>>>>> addition, I later saw that you were +0, so I added ALL back.
>>>>> 3、the change to Parse.g will be like :
>>>>>
>>>>>> /**
>>>>>> * CREATE TABLE [IF NOT EXISTS] <NEW_TABLE>
>>>>>> * LIKE <OLD_TABLE>
>>>>>> * [ WITH OPTIONS AND INDEXES AND TRIGGERS ]
>>>>>> */
>>>>>> copyTableStatement returns [CopyTableStatement.Raw stmt]
>>>>>> @init { boolean ifNotExists = false; }
>>>>>> : K_CREATE K_COLUMNFAMILY newCf=columnFamilyName LIKE
>>>>>> oldCf=columnFamilyName
>>>>>> { $stmt = new CopyTableStatement.Raw(newCf, oldCf); }
>>>>>> tableLikeOptions[stmt]
>>>>>> ;
>>>>>>
>>>>>> tableLikeOptions[CopyTableStatement.Raw stmt]
>>>>>> : ( K_WITH tableLikeSingleOption[stmt] ( K_AND
>>>>>> tableLikeSingleOption[stmt] )*)?
>>>>>> ;
>>>>>>
>>>>>> tableLikeSingleOption[CopyTableStatement.Raw stmt]
>>>>>> : option=STRING_LITERAL { $stmt.extendWithLikeOptions($option.text);
>>>>>> }
>>>>>> ;
>>>>>>
>>>>>> I don’t plan to reuse the Create table definition file, and there
>>>>> doesn’t seem to be much need. And I have made a explanation in the cep
>>>>> file
>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Štefan Miklošovič <smikloso...@apache.org> 于2024年11月4日周一 17:00写道：
>>>>>
>>>>>> Hi Maxwell,
>>>>>>
>>>>>> 1) I noticed that there is table copying across keyspaces in your
>>>>>> goal number 2) in the CEP. Is this correct? I was thinking that we are
>>>>>> doing same-keyspace copying for now and it will be considered later, as
>>>>>> you
>>>>>> elaborate on that further down the document. Cross-keyspace copying would
>>>>>> mean (among other things) that we would need to create UDTs in another
>>>>>> keyspace as well which would complicate it etc ...
>>>>>>
>>>>>> 2) I also see this
>>>>>>
>>>>>> CREATE TABLE <NEW_TABLE> LIKE <OLD_TABLE> [ WITH ALL | [ INDEXES AND
>>>>>> TRIGGERS]]
>>>>>>
>>>>>> Is this really correct? I think we agreed that ALL will not be
>>>>>> supported. You gave up on ALL in this comment of yours (the first
>>>>>> sentence)
>>>>>> (1)
>>>>>>
>>>>>> 3) It would be great if you were more explicit about the proposed CQL
>>>>>> changes in such a way that after the CEP is delivered, it would be
>>>>>> possible
>>>>>> to override the options on a new table. Basically what Dave summarized
>>>>>> here
>>>>>> (2) at the very bottom. All three examples should be mentioned in CEP for
>>>>>> being explicit about our intentions.
>>>>>>
>>>>>> After this is all reflected, I will be glad to vote on this CEP in
>>>>>> the other thread.
>>>>>>
>>>>>> (1) https://lists.apache.org/thread/d485w6lxvpoztmjnxj8msj0jjt3d5ltk
>>>>>> (2) https://lists.apache.org/thread/odc1s1pt5m2tk76owxq61y55kytf13sf
>>>>>>
>>>>>> On Wed, Oct 30, 2024 at 4:28 AM guo Maxwell <cclive1...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> So we should be able to start voting on this now.
>>>>>>>
>>>>>>> guo Maxwell <cclive1...@gmail.com> 于2024年10月28日周一 17:20写道：
>>>>>>>
>>>>>>>> Here is the latest updated CEP-43
>>>>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>>>>>>>
>>>>>>>>
>>>>>>>> guo Maxwell <cclive1...@gmail.com> 于2024年10月24日周四 19:53写道：
>>>>>>>>
>>>>>>>>> yes，you are right. I will add this
>>>>>>>>>
>>>>>>>>> Štefan Miklošovič <smikloso...@apache.org>于2024年10月24日 周四下午4:42写道：
>>>>>>>>>
>>>>>>>>>> The CEP should also mention that copying system tables or virtual
>>>>>>>>>> tables or materialized views and similar are not supported and an
>>>>>>>>>> attempt
>>>>>>>>>> of doing so will error out.
>>>>>>>>>>
>>>>>>>>>> On Thu, Oct 24, 2024 at 7:16 AM Dave Herrington <
>>>>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Strong +1 to copy all options by default. This is intuitive to
>>>>>>>>>>> me. Then I would like to explicitly override any options of my
>>>>>>>>>>> choosing.
>>>>>>>>>>>
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 23, 2024 at 9:57 PM guo Maxwell <
>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> OK，thank you for your suggestions ，I will revise the CEP and
>>>>>>>>>>>> copy table OPTIONS by default.
>>>>>>>>>>>>
>>>>>>>>>>>> Jon Haddad <j...@rustyrazorblade.com>于2024年10月23日 周三下午9:18写道：
>>>>>>>>>>>>
>>>>>>>>>>>>> Also strongly +1 to copying all the options.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Oct 23, 2024 at 5:52 AM Josh McKenzie <
>>>>>>>>>>>>> jmcken...@apache.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm a very strong +1 to having the default functionality be
>>>>>>>>>>>>>> to copy *ALL* options.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Intuitively, as a user, if I tell a software system to make a
>>>>>>>>>>>>>> clone of something I don't expect it to be shallow or a subset
>>>>>>>>>>>>>> defined by
>>>>>>>>>>>>>> some external developer somewhere. I expect it to be a clone.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Adding in some kind of "lean" mode or "column only" is fine
>>>>>>>>>>>>>> if someone can make a cogent argument around its inclusion. I
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>> personally see a use-case for it right now but definitely open
>>>>>>>>>>>>>> to being
>>>>>>>>>>>>>> educated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Oct 23, 2024, at 3:03 AM, Štefan Miklošovič wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> options are inherently part of that table as well, same as
>>>>>>>>>>>>>> schema. In fact, _schema_ includes all options. Not just columns
>>>>>>>>>>>>>> and its
>>>>>>>>>>>>>> names. If you change some option, you effectively have a
>>>>>>>>>>>>>> different schema,
>>>>>>>>>>>>>> schema version changes by changing an option. So if we do not
>>>>>>>>>>>>>> copy options
>>>>>>>>>>>>>> too, we are kind of faking it (when we do not specify WITH
>>>>>>>>>>>>>> OPTIONS).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, imagine a situation where Accord is merged to trunk. It
>>>>>>>>>>>>>> introduces a new schema option called "transactional = full"
>>>>>>>>>>>>>> which is not
>>>>>>>>>>>>>> default. (I am sorry if I did the spelling wrong here). So, when
>>>>>>>>>>>>>> you have a
>>>>>>>>>>>>>> table with transactional support and you do "create table
>>>>>>>>>>>>>> ks.tb_copy like
>>>>>>>>>>>>>> ks.tb", when you _do not_ copy all options, this table will
>>>>>>>>>>>>>> _not_ become
>>>>>>>>>>>>>> transactional.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The next thing you go to do is to execute some transactions
>>>>>>>>>>>>>> against this table but well ... you can not do that, because
>>>>>>>>>>>>>> your table is
>>>>>>>>>>>>>> not transactional, because you have forgotten to add "WITH
>>>>>>>>>>>>>> OPTIONS". So you
>>>>>>>>>>>>>> need to go back to that and do "ALTER ks.tb_copy WITH
>>>>>>>>>>>>>> transactional = full"
>>>>>>>>>>>>>> just to support that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think that you see from this pattern that it is way better
>>>>>>>>>>>>>> if we copy all options by default instead of consciously opt-in
>>>>>>>>>>>>>> into them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> also:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "but I think there are also some users want to do basic
>>>>>>>>>>>>>> column information copy"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> where is this coming from? Do you have this idea somehow
>>>>>>>>>>>>>> empirically tested? I just do not see why somebody would want to
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> Cassandra's defaults instead of what a base table contains.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Oct 23, 2024 at 8:28 AM guo Maxwell <
>>>>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The reason for using OPTION keyword is that I want to provide
>>>>>>>>>>>>>> users with more choices .
>>>>>>>>>>>>>> The default behavior for copying a table is to copy the basic
>>>>>>>>>>>>>> item of table （column and their data
>>>>>>>>>>>>>> type，mask，constraint），others thing
>>>>>>>>>>>>>> belongs to the table like option，views，trigger
>>>>>>>>>>>>>> are optional in my mind.
>>>>>>>>>>>>>> You are absolutely right that users may want to copy all
>>>>>>>>>>>>>> stuff but I think there are aslo some users want to do basic
>>>>>>>>>>>>>> column
>>>>>>>>>>>>>> information copy，So I just give them a choice。As we know that
>>>>>>>>>>>>>> the number of
>>>>>>>>>>>>>> table parameters is not
>>>>>>>>>>>>>> small，compression，compaction，gc_seconds，bf_chance，speculative_retry
>>>>>>>>>>>>>> and so
>>>>>>>>>>>>>> on.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Besides we can see that pg have also the keyword
>>>>>>>>>>>>>> COMMENT，COMPRESSION which have the similar behavior as our
>>>>>>>>>>>>>> OPTION keyword。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So that is why I add this keyword OPTION.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Štefan Miklošovič <smikloso...@apache.org>于2024年10月22日
>>>>>>>>>>>>>> 周二下午11:40写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The problem is that when I do this minimal CQL which shows
>>>>>>>>>>>>>> this feature:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> CREATE TABLE ks.tb_copy LIKE ks.tb;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> then you are saying that when I _do not_ specify WITH OPTIONS
>>>>>>>>>>>>>> then I get Cassandra's defaults. Only after I specify WITH
>>>>>>>>>>>>>> OPTIONS, it
>>>>>>>>>>>>>> would truly be a copy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is not a good design. Because to have an exact copy, I
>>>>>>>>>>>>>> have to make a conscious effort to include OPTIONS as well. That
>>>>>>>>>>>>>> should not
>>>>>>>>>>>>>> be the case. I just want to have a copy, totally the same stuff,
>>>>>>>>>>>>>> when I use
>>>>>>>>>>>>>> the minimal version of that statement. It would be better to
>>>>>>>>>>>>>> opt-out from
>>>>>>>>>>>>>> options like
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> CREATE TABLE ks.tb_copy LIKE ks.tb WITHOUT OPTIONS (you feel
>>>>>>>>>>>>>> me) but we do not support this (yet).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Oct 22, 2024 at 5:28 PM Štefan Miklošovič <
>>>>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I just don't see OPTIONS as important. When I want to copy a
>>>>>>>>>>>>>> table, I am copying a table _with everything_. Options included,
>>>>>>>>>>>>>> by
>>>>>>>>>>>>>> default. Why would I want to have a copy of a table with options
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>> from the base one?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Oct 21, 2024 at 3:55 PM Bernardo Botella <
>>>>>>>>>>>>>> conta...@bernardobotella.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Guo,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +1 for the CONSTRAINTS keyword to be added into the default
>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bernardo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Oct 21, 2024, at 12:01 AM, guo Maxwell <
>>>>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think the CONSTRAINTS keyword keyword may be in the same
>>>>>>>>>>>>>> situation as datamask.
>>>>>>>>>>>>>> Maybe it is better to include constraints into the default
>>>>>>>>>>>>>> behavior of table copy together with column name, column data
>>>>>>>>>>>>>> type and data
>>>>>>>>>>>>>> mask.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> guo Maxwell <cclive1...@gmail.com> 于2024年10月21日周一 14:56写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To yifan :
>>>>>>>>>>>>>> I don't mind adding the ALL keyword, and it has been updated
>>>>>>>>>>>>>> into CEP.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As all you can see, our original intention was that the
>>>>>>>>>>>>>> grammar would not be too complicated, which is what I described
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> cep
>>>>>>>>>>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>> We gave up PG-related grammar, including INCLUDING/EXCLUDING
>>>>>>>>>>>>>> and so on .
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> guo Maxwell <cclive1...@gmail.com> 于2024年10月21日周一 14:52写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi ,
>>>>>>>>>>>>>> To sefan :
>>>>>>>>>>>>>> I may want to explain that if there is no OPTION keyword in
>>>>>>>>>>>>>> the CQL statement, then the newly created table will only have
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> original table's column name 、column type and data mask ,I
>>>>>>>>>>>>>> think this is
>>>>>>>>>>>>>> the most basic choice when copying tables to users.
>>>>>>>>>>>>>> Then we do some addition, we can add original table's table
>>>>>>>>>>>>>> options like compaction strategy/compress strategy、index and so
>>>>>>>>>>>>>> on.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Recently, I have also thought about the situation of
>>>>>>>>>>>>>> CONSTRAINTS keyword. I think it is similar to data mask. Agree
>>>>>>>>>>>>>> that it
>>>>>>>>>>>>>> should be included in the basic options of table copy (column
>>>>>>>>>>>>>> name, column
>>>>>>>>>>>>>> data type , column data mask and constraints).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dave Herrington <he...@rhinosource.com> 于2024年10月19日周六
>>>>>>>>>>>>>> 01:15写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It seems like a natural extension of the CREATE TABLE
>>>>>>>>>>>>>> statement. Looking forward to using it in the future.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Oct 17, 2024 at 5:11 PM Štefan Miklošovič <
>>>>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right?! Reads like English, the impact on the existing CQL is
>>>>>>>>>>>>>> minimal. One LIKE which basically needs to be there and keywords
>>>>>>>>>>>>>> of logical
>>>>>>>>>>>>>> "components" which seamlessly integrate with WITH.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would _not_ use WITH CONSTRAINTS because constraints will
>>>>>>>>>>>>>> be inherently part of a table schema. It is not an "option". We
>>>>>>>>>>>>>> can not
>>>>>>>>>>>>>> "opt-out" from them. Remember we are copying a table here so if
>>>>>>>>>>>>>> a base one
>>>>>>>>>>>>>> has constraints, its copy will have them too. A user can
>>>>>>>>>>>>>> subsequently
>>>>>>>>>>>>>> "ALTER" them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Oct 17, 2024 at 5:31 PM Dave Herrington <
>>>>>>>>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Basing it on CREATE TABLE, the BNF definition of the simple
>>>>>>>>>>>>>> implementation would look something like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> create_table_statement::= CREATE TABLE [ IF NOT EXISTS ]
>>>>>>>>>>>>>> table_name LIKE base_table_name
>>>>>>>>>>>>>> [ WITH included_objects ] [ [ AND ] table_options ]
>>>>>>>>>>>>>> table_options::= COMPACT STORAGE [ AND table_options ]
>>>>>>>>>>>>>> | CLUSTERING ORDER BY '(' clustering_order ')'
>>>>>>>>>>>>>> [ AND table_options ] | options
>>>>>>>>>>>>>> clustering_order::= column_name (ASC | DESC) ( ','
>>>>>>>>>>>>>> column_name (ASC | DESC) )*
>>>>>>>>>>>>>> included_objects::= dependent_objects [ AND dependent_objects
>>>>>>>>>>>>>> ]
>>>>>>>>>>>>>> dependent_objects:= INDEXES | TRIGGERS | CONSTRAINTS | VIEWS
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> CREATE TABLE [ IF NOT EXISTS ] [<keyspace_name>.]<table_name>
>>>>>>>>>>>>>> LIKE [<keyspace_name>.]<base_table_name>
>>>>>>>>>>>>>> [ WITH [ <included_objects > ]
>>>>>>>>>>>>>> [ [ AND ] [ <table_options> ] ]
>>>>>>>>>>>>>> [ [ AND ] CLUSTERING ORDER BY [ <clustering_column_name>
>>>>>>>>>>>>>> (ASC | DESC) ] ]
>>>>>>>>>>>>>> ;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Examples:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Create base table:
>>>>>>>>>>>>>> CREATE TABLE cycling.cyclist_name (
>>>>>>>>>>>>>> id UUID PRIMARY KEY,
>>>>>>>>>>>>>> lastname text,
>>>>>>>>>>>>>> firstname text
>>>>>>>>>>>>>> );
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Create an exact copy of the base table, but do not create
>>>>>>>>>>>>>> any dependent objects:
>>>>>>>>>>>>>> CREATE TABLE cycling.cyclist_name2 LIKE cycling.cyclist_name;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Create an exact copy with all dependent objects
>>>>>>>>>>>>>> (constraints excluded for now):
>>>>>>>>>>>>>> CREATE TABLE cycling.cyclist_name3 LIKE cycling.cyclist_name
>>>>>>>>>>>>>> WITH INDEXES AND TRIGGERS AND VIEWS;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Create a copy with LCS compaction, a default TTL and all
>>>>>>>>>>>>>> dependent objects except indexes:
>>>>>>>>>>>>>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
>>>>>>>>>>>>>> WITH TRIGGERS AND VIEWS
>>>>>>>>>>>>>> AND compaction = { 'class' : 'LeveledCompactionStrategy' }
>>>>>>>>>>>>>> AND default_time_to_live = 86400;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This seems pretty clean & straightforward.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Oct 17, 2024 at 4:05 PM Dave Herrington <
>>>>>>>>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This simple approach resonates with me. I think the
>>>>>>>>>>>>>> Cassandra doc uses "INDEXES" as the plural for index, i.e.:
>>>>>>>>>>>>>> https://cassandra.apache.org/doc/stable/cassandra/cql/indexes.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Oct 17, 2024 at 2:39 PM Štefan Miklošovič <
>>>>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well we could do something like:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> CREATE TABLE ks.tb_copy LIKE ks.tb WITH INDICES AND TRIGGERS
>>>>>>>>>>>>>> AND compaction = {'class': '.... } AND ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> but I can admit it might be seen as an overreach and I am not
>>>>>>>>>>>>>> sure at all how it would look like in the implementation because
>>>>>>>>>>>>>> we would
>>>>>>>>>>>>>> need to distinguish WITH INDICES from table options.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. +0 on ALL. - we don't need this. If we have just
>>>>>>>>>>>>>> INDICES, TRIGGERS, VIEWS at this point, I don't think
>>>>>>>>>>>>>> enumerating it all is
>>>>>>>>>>>>>> too much to ask. This is just an implementation detail and if
>>>>>>>>>>>>>> we find it
>>>>>>>>>>>>>> necessary we can add it later. If you feel strongly about
>>>>>>>>>>>>>> this then add
>>>>>>>>>>>>>> that but it is not absolutely necessary.
>>>>>>>>>>>>>> 2. omit OPTIONS - aren't all options copied by default?
>>>>>>>>>>>>>> That is the goal of the CEP, no? We might just use normal
>>>>>>>>>>>>>> CQL while overriding from the base table
>>>>>>>>>>>>>> 3. mix keywords like TRIGGERS / INDICES / CONSTRAINTS
>>>>>>>>>>>>>> into normal table creation statement
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Oct 17, 2024 at 3:20 PM Yifan Cai <yc25c...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would second Štefan's option for functionality simplicity.
>>>>>>>>>>>>>> It seems to be unnecessary to have the keywords for both
>>>>>>>>>>>>>> inclusion and
>>>>>>>>>>>>>> exclusion in the CEP. If needed, the exclusion (WITHOUT) can be
>>>>>>>>>>>>>> introduced
>>>>>>>>>>>>>> later. It would still be backward compatible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regarding "CREATE TABLE ks.tb_copy LIKE ks.tb WITH compaction
>>>>>>>>>>>>>> = {'class': '.... } AND ... ", I think it only overrides the
>>>>>>>>>>>>>> table options.
>>>>>>>>>>>>>> The CEP suggests the coarse-grained keyword for each category
>>>>>>>>>>>>>> like table
>>>>>>>>>>>>>> options, indexes, etc. The functionality provided is not
>>>>>>>>>>>>>> identical.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I understand that the suggestions are to make operators' life
>>>>>>>>>>>>>> easier by achieving table creation in a single statement. What
>>>>>>>>>>>>>> is being
>>>>>>>>>>>>>> proposed in the CEP seems to be at a good balance point.
>>>>>>>>>>>>>> Operators can
>>>>>>>>>>>>>> alter the table options if needed in the follow-up ALTER table
>>>>>>>>>>>>>> statement.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Yifan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Oct 17, 2024 at 1:41 PM Štefan Miklošovič <
>>>>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think we are starting to complicate it. For me the most
>>>>>>>>>>>>>> important question is who is actually this feature for? If
>>>>>>>>>>>>>> people want to
>>>>>>>>>>>>>> just prototype something fast or they just want to have "the
>>>>>>>>>>>>>> same table
>>>>>>>>>>>>>> just under a different name", I think that is going to be used
>>>>>>>>>>>>>> in 99% of
>>>>>>>>>>>>>> cases.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My assumption of using WITH which I think I proposed first
>>>>>>>>>>>>>> (4th post in this thread) was to just blindly copy the most
>>>>>>>>>>>>>> important
>>>>>>>>>>>>>> "parts" logically related to a table, be it indices,
>>>>>>>>>>>>>> materialized views, or
>>>>>>>>>>>>>> triggers and enable / disable them as we wish. If no "WITH" is
>>>>>>>>>>>>>> used, then
>>>>>>>>>>>>>> we just get a table with nothing else. "WITH" will opt-in into
>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Seeing us contemplating using "INCLUDING" and "EXCLUDING" on
>>>>>>>>>>>>>> individual options makes me sad a little bit. I think we are
>>>>>>>>>>>>>> over-engineering this. I just don't see a reasonable use-case
>>>>>>>>>>>>>> where users
>>>>>>>>>>>>>> would need to cherry-pick what they want and what not. Isn't
>>>>>>>>>>>>>> that just too
>>>>>>>>>>>>>> complicated? If a table being copied drifts away too much from
>>>>>>>>>>>>>> the original
>>>>>>>>>>>>>> one then users would be better off with creating a brand new
>>>>>>>>>>>>>> table with CQL
>>>>>>>>>>>>>> as they are used to, not dealing with "copying" at all. More we
>>>>>>>>>>>>>> drift from
>>>>>>>>>>>>>> what the original table was like, the less useful this feature
>>>>>>>>>>>>>> is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Oct 16, 2024 at 10:03 PM Dave Herrington <
>>>>>>>>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sorry that I overlooked the definition of the default in the
>>>>>>>>>>>>>> CEP. I did look for it but I didn’t see it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think the default behavior you explained makes perfect
>>>>>>>>>>>>>> sense & what one would expect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I like the flexibility of INCLUDING and EXCLUDING that you
>>>>>>>>>>>>>> are considering.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would it make sense to use WITH for table options, which
>>>>>>>>>>>>>> would make it easy (and less confusing IMHO) to override the
>>>>>>>>>>>>>> defaults from
>>>>>>>>>>>>>> the source table, then use INCLUDING/EXCLUDING for all non-table
>>>>>>>>>>>>>> options
>>>>>>>>>>>>>> such as constraints and indices?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It seems this would be easier to document as well, as it
>>>>>>>>>>>>>> could just point to the CREATE TABLE doc for the options, rather
>>>>>>>>>>>>>> than
>>>>>>>>>>>>>> trying to explain a bunch of keywords that map to table options.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced
>>>>>>>>>>>>>> Analytics.*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Oct 16, 2024 at 7:57 PM guo Maxwell <
>>>>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To yifan :
>>>>>>>>>>>>>> At the beginning of the period, I also thought about adding
>>>>>>>>>>>>>> the keyword ALL, refer to pg
>>>>>>>>>>>>>> <https://www.postgresql.org/docs/current/sql-createtable.html> ,
>>>>>>>>>>>>>> but I give up when writing cep as I find that there may be not
>>>>>>>>>>>>>> so many
>>>>>>>>>>>>>> properties (only three) to copy for C* and
>>>>>>>>>>>>>> It is possible to decide what is needed and what is not in a
>>>>>>>>>>>>>> very simple cql, as our ALL is only three properties here. I
>>>>>>>>>>>>>> want to keep
>>>>>>>>>>>>>> it as simple as possible (based on the advice given by
>>>>>>>>>>>>>> Benjamin), So I
>>>>>>>>>>>>>> grouped
>>>>>>>>>>>>>> the properties of the table into one category and expressed
>>>>>>>>>>>>>> it with OPTION keyword.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But if we are going to split the first keyword OPTION to
>>>>>>>>>>>>>> COMPRESSION 、COMPACTION、COMMENT and so on. I am +1 on adding ALL
>>>>>>>>>>>>>> back as
>>>>>>>>>>>>>> the properties are so many and it is simple to use ALL instead of
>>>>>>>>>>>>>> list all properties. Besides I may change my keyword WITH to
>>>>>>>>>>>>>> INCLUDING and adding another keyword EXCLUDING to flexibly copy
>>>>>>>>>>>>>> table
>>>>>>>>>>>>>> properties through simple sql statements, like using 1 not 2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. CREATE TABLE newTb like oldTb INCLUDING ALL EXCLUDING
>>>>>>>>>>>>>> INDEXES AND COMMENTS.
>>>>>>>>>>>>>> 2. CREATE TABLE newTb like oldTb INCLUDING COMPRESSION
>>>>>>>>>>>>>> CONSTRAINTS GENERATED IDENTITY STATISTICS STORAGE
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Conclusion: If there may be more keywords to consider in the
>>>>>>>>>>>>>> future, such as more than 4 , I am +1 on adding ALL back .
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To Dave :
>>>>>>>>>>>>>> Default behavior is only copy column name, data type
>>>>>>>>>>>>>> ,data mask , you can see more detail from CEP-43
>>>>>>>>>>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Patrick McFadin <pmcfa...@gmail.com> 于2024年10月17日周四 06:43写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +1 That makes much more sense in my experience.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Oct 16, 2024 at 12:12 PM Dave Herrington <
>>>>>>>>>>>>>> he...@rhinosource.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm coming at this with both a deep ANSI SQL background as
>>>>>>>>>>>>>> well as CQL background.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Defining the default behavior is the starting point. What
>>>>>>>>>>>>>> gets copied if we do "CREATE TABLE new_table LIKE
>>>>>>>>>>>>>> original_table;" without
>>>>>>>>>>>>>> a WITH clause?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then, you build on that with the specific WITH options. WITH
>>>>>>>>>>>>>> ALL catches everything.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Oct 16, 2024 at 11:16 AM Yifan Cai <
>>>>>>>>>>>>>> yc25c...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "WITH ALL" seems to be a natural addition to the directives.
>>>>>>>>>>>>>> What do you think about adding the fifth keyword ALL to retain
>>>>>>>>>>>>>> all fields
>>>>>>>>>>>>>> of the table schema?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For instance, CREATE TABLE new_table LIKE original_table WITH
>>>>>>>>>>>>>> ALL, it replicates options, indexes, triggers, constraints and
>>>>>>>>>>>>>> any
>>>>>>>>>>>>>> applicable kinds that are introduced in the future.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Yifan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Oct 16, 2024 at 7:46 AM guo Maxwell <
>>>>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Disscussed with Bernardo on slack，and +1 with his advice on
>>>>>>>>>>>>>> adding a fourth keyword.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The keyword would be CONSTRAINTS ， any more suggestion ？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> guo Maxwell <cclive1...@gmail.com>于2024年10月16日 周三上午9:55写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <yc25c...@gmail.com> 于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 <
>>>>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello, everyone ,
>>>>>>>>>>>>>> I have finished the doc for CEP-43 for CREATE_TABLE_LIKE
>>>>>>>>>>>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-43++Apache+Cassandra+CREATE+TABLE++LIKE>
>>>>>>>>>>>>>> as
>>>>>>>>>>>>>> said before, looking forward to your suggestions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Štefan Miklošovič <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 <
>>>>>>>>>>>>>> cclive1...@gmail.com> 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 <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č <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 <
>>>>>>>>>>>>>> cclive1...@gmail.com> 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
>>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/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
>>>>>>>>>>>>>> <https://www.postgresql.org/docs/8.1/sql-createtable.html> ,
>>>>>>>>>>>>>> the new created index name is different from the original
>>>>>>>>>>>>>> table's index
>>>>>>>>>>>>>> name , seenewly copied index names are different from
>>>>>>>>>>>>>> original
>>>>>>>>>>>>>> <https://github.com/postgres/postgres/blob/master/doc/src/sgml/ref/create_table.sgml#L749>
>>>>>>>>>>>>>> , the name is based on some rule.
>>>>>>>>>>>>>> Mysql is relatively simple and copies columns and indexes by
>>>>>>>>>>>>>> default. see mysql create table like
>>>>>>>>>>>>>> <https://dev.mysql.com/doc/refman/8.4/en/create-table-like.html>
>>>>>>>>>>>>>> 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 <cclive1...@gmail.com> 于2024年9月20日周五 08:06写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No，I think still need some discuss on grammar detail after I
>>>>>>>>>>>>>> finish the first version
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Patrick McFadin <pmcfa...@gmail.com>于2024年9月20日 周五上午2:24写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is this CEP ready for a VOTE thread?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Aug 24, 2024 at 8:56 PM guo Maxwell <
>>>>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you for your replies, I will prepare a CEP later.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Patrick McFadin <pmcfa...@gmail.com> 于2024年8月20日周二 02:11写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +1 This is a CEP
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Aug 19, 2024 at 10:50 AM Jon Haddad <
>>>>>>>>>>>>>> j...@jonhaddad.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Given the fairly large surface area for this, i think it
>>>>>>>>>>>>>> should be a CEP.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> —
>>>>>>>>>>>>>> Jon Haddad
>>>>>>>>>>>>>> Rustyrazorblade Consulting
>>>>>>>>>>>>>> rustyrazorblade.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Aug 19, 2024 at 10:44 AM Bernardo Botella <
>>>>>>>>>>>>>> conta...@bernardobotella.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Definitely a nice addition to CQL.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking for inspiration at how Postgres and Mysql do that may
>>>>>>>>>>>>>> also help with the final design (I like the WITH proposed by
>>>>>>>>>>>>>> Stefan, but I
>>>>>>>>>>>>>> would definitely take a look at the INCLUDING keyword proposed
>>>>>>>>>>>>>> by Postgres).
>>>>>>>>>>>>>> https://www.postgresql.org/docs/current/sql-createtable.html
>>>>>>>>>>>>>> https://dev.mysql.com/doc/refman/8.4/en/create-table-like.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On top of that, and as part of the interesting questions, I
>>>>>>>>>>>>>> would like to add the permissions to the mix. Both the question
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>> copying them over (with a WITH keyword probably), and the need
>>>>>>>>>>>>>> for read
>>>>>>>>>>>>>> permissions on the source table as well.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bernardo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Aug 19, 2024, at 10:01 AM, Štefan Miklošovič <
>>>>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> BTW this would be cool to do as well:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ALTER TABLE ks.to_copy LIKE ks.tb WITH INDICES;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would mean that if we create a copy of a table, later we
>>>>>>>>>>>>>> can decide that we need indices too, so we might "enrich" that
>>>>>>>>>>>>>> table with
>>>>>>>>>>>>>> indices from the old one without necessarily explicitly
>>>>>>>>>>>>>> re-creating them on
>>>>>>>>>>>>>> that new table.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Aug 19, 2024 at 6:55 PM Štefan Miklošovič <
>>>>>>>>>>>>>> smikloso...@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think this is an interesting idea worth exploring. I
>>>>>>>>>>>>>> definitely agree with Benjamin who raised important questions
>>>>>>>>>>>>>> which needs
>>>>>>>>>>>>>> to be answered first. Also, what about triggers?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It might be rather "easy" to come up with something simple
>>>>>>>>>>>>>> but it should be a comprehensive solution with predictable
>>>>>>>>>>>>>> behavior we all
>>>>>>>>>>>>>> agree on.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If a keyspace of a new table does not exist we would need to
>>>>>>>>>>>>>> create that one too before. For the simplicity, I would just
>>>>>>>>>>>>>> make it a must
>>>>>>>>>>>>>> to create it on same keyspace. We might iterate on that in the
>>>>>>>>>>>>>> future.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> UDTs are created per keyspace so there is nothing to
>>>>>>>>>>>>>> re-create. We just need to reference it from a new table, right?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Indexes and MVs are interesting but in theory they might be
>>>>>>>>>>>>>> re-created too.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would it be appropriate to use something like this?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> CREATE TABLE ks.tb_copy LIKE ks.tb WITH INDEXES AND VIEWS AND
>>>>>>>>>>>>>> TRIGGERS ....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Without "WITH" it would just copy a table with nothing else.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Aug 19, 2024 at 6:10 PM guo Maxwell <
>>>>>>>>>>>>>> cclive1...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello， everyone：
>>>>>>>>>>>>>> As Jira CASSANDRA-7662
>>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/CASSANDRA-7662> has
>>>>>>>>>>>>>> described , we would like to introduce a new grammer " CREATE
>>>>>>>>>>>>>> TABLE LIKE "
>>>>>>>>>>>>>> ,which simplifies creating new tables duplicating the existing
>>>>>>>>>>>>>> ones .
>>>>>>>>>>>>>> The format may be like : CREATE TABLE <new_table> LIKE
>>>>>>>>>>>>>> <old_table>
>>>>>>>>>>>>>> Before I implement this function, do you have any suggestions
>>>>>>>>>>>>>> on this?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking forward to your reply！
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced
>>>>>>>>>>>>>> Analytics.*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced
>>>>>>>>>>>>>> Analytics.*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced
>>>>>>>>>>>>>> Analytics.*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David A. Herrington II
>>>>>>>>>>>>>> President and Chief Engineer
>>>>>>>>>>>>>> RhinoSource, Inc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Data Lake Architecture, Cloud Computing and Advanced
>>>>>>>>>>>>>> Analytics.*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> www.rhinosource.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
