I agree, and triggers are an expert feature anyway so I wouldn't expect them to be copied.
Kind Regards, Brandon On Fri, Jan 31, 2025 at 12:46 PM Štefan Miklošovič <smikloso...@apache.org> wrote: > > Thank you Maxwell for reaching ML with this. > > I was talking to Maxwell about a feature where CREATE TABLE LIKE would also > support triggers. > > create table ks.tb_copy like ks.tb with triggers > > "with triggers" would be added to CQL grammar and it would "copy" what that > trigger(s) is / are doing. > > While this is technically possible to do, I am not completely sure it is the > right thing to do. If you take a look into examples/triggers (we have this > dir in the repository), there is an example of a trigger which is parsing > keyspace / table to operate on from the configuration file > (examples/triggers/conf/AuditTrigger.properties). > > If a user copies a table like this, then, sure, a trigger will be copied as > well, but it will not match anymore. > > My argument against supporting copying triggers is that when we can not > guarantee that it will work _in all cases_, then I would say that we should > not be supporting this. > > On Fri, Jan 31, 2025 at 6:06 PM guo Maxwell <cclive1...@gmail.com> wrote: >> >> Hello dev, >> I'm very sorry to disturb everyone's wonderful weekend time. Please allow >> me to ask about the trigger in Cassandra? >> Maybe everyone knows some implementations of Cassandra's trigger. If the >> user needs it to do something, it may be >> necessary to package the jar we need and load the corresponding class to do >> something similar to preprocessing on the write path. >> So my question here is : Are we fine with the current implementation here, >> Should we support triggers in new features ? >> I encountered this problem recently, we are also discussing whether we need >> to continue to support trigger's clone in CEP-43 (CREATE TABLE LIKE)? >> >> Looking forward to your reply.
