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