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