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
